Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Атомарность операций над стандартными типами C++  (Прочитано 20474 раз)
0 Пользователей и 1 Гость смотрят эту тему.
PredatorAlpha
Помогающий

ua
Offline Offline

« Ответ #30 : 11-08-2011 12:15 » new

Там используется то, что деструкторы локальных объектов вызываются в любом случае, даже если return где-то в теле или возникло исключение. Очень удобная штука для освобождения ресурсов.
Просто Ochkarik больше на классическом С работает...
Записан
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #31 : 11-08-2011 12:20 » 

а в каком месте та переменная то стоит, которую синхронизировать надо было?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
RuNTiME
Помогающий

ru
Offline Offline
Пол: Мужской

« Ответ #32 : 11-08-2011 12:24 » 

Ochkarik, Тут просто пояснение почему и как работает MutexLocker. Переменную смотри в начале, где я выкладывал код класса Thread.
Записан

Любимая игрушка - debugger ...
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #33 : 11-08-2011 14:17 » 

я просто за основной алгоритм принял фразу:
"Есть переменная, тип int. Два потока пишут в эту переменную, а третий считывает значение этой переменной."
и для этого - функции ожидания не нужны.

а на самом деле, вам еще и функции ожидания была жизненно необходима?

Просто Ochkarik больше на классическом С работает...
есть немного))))
« Последнее редактирование: 11-08-2011 14:26 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
PredatorAlpha
Помогающий

ua
Offline Offline

« Ответ #34 : 11-08-2011 14:36 » 

Просто Ochkarik больше на классическом С работает...
есть немного))))
Я сам такой...
Embedded-программер..
Записан
RuNTiME
Помогающий

ru
Offline Offline
Пол: Мужской

« Ответ #35 : 11-08-2011 15:36 » 

Ochkarik,
Цитата
а на самом деле, вам еще и функции ожидания была жизненно необходима?
Изначально мне нужно было только лишь узнать, можно ли безопасно считывать значение этой самой переменной. И я сформулировал только суть. Ну, а раз уж тему развили, почему бы и не по обсуждать связанные с этим проблемы... Улыбаюсь
Записан

Любимая игрушка - debugger ...
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #36 : 11-08-2011 15:46 » 

тады - ой)
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #37 : 12-08-2011 04:22 » 

ну и очередные мои 5 копеек Улыбаюсь
lock не блокирует шину, времена те давно минули
lock блокирует кэш линию

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят Улыбаюсь
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах

PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые?
PPS: а сравнительные тесты будут?
PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса
Записан

Странно всё это....
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #38 : 12-08-2011 05:28 » 

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят Улыбаюсь
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах
Прошу прощения, но, imho, asm к mutex-ам/futex-ам имеет опосредованное значение, и, насколько я помню, futex-ом называется один из базовых примитивов синхронизации в linux, который был реализован при переходе с Linuxthreads на NPTL. Кроме того, определённый объект ядра там используется - очередь ожидания, иначе как ядро обеспечит ожидание нескольких потоков (По крайней мере так написано в документе The Native POSIX Thread Library for Linux).
« Последнее редактирование: 12-08-2011 05:38 от darkelf » Записан
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #39 : 12-08-2011 05:39 » 

darkelf, что-то я про это совсем забыл Улыбаюсь вот я раздолбай, давно много потоковые системы не строил
Записан

Странно всё это....
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #40 : 12-08-2011 06:47 » 

пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят Улыбаюсь
обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах

Собственно, расположив их в разделяемой памяти можно и межпроцессное взаимодействие осуществлять без участия ядра.


Добавлено через 2 минуты и 45 секунд:
darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика.
« Последнее редактирование: 12-08-2011 06:50 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
RuNTiME
Помогающий

ru
Offline Offline
Пол: Мужской

« Ответ #41 : 12-08-2011 07:01 » 

PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые?
По двум причинам:
Первая и основная углубленное изучение многопоточного программирования (ну хочется мне).
А вторая банальная - свести к минимуму кол-во зависимостей.

PPS: а сравнительные тесты будут?
Сравнивать пока нечего да и основные задачи библиотеки не реализация классов для написания многопоточных приложений.

PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса
За наводку на tbb спасибо. Вчера еще скачал эту библиотеку. Будет с чего брать пример.
boost - очень уж громоздок если использовать его только для запуска потоков
Записан

Любимая игрушка - debugger ...
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #42 : 12-08-2011 07:28 » 

Добавлено через 2 минуты и 45 секунд:
darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика.
Imho, yield(), требует как входа в ядро, так и использования очереди - в случае, если есть более высокоприоритетные процессы/потоки текущий процесс надо будет приостановить, соответственно, поставить в очередь ожидания и выполнить переключение контекста на более приоритетный.
Записан
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #43 : 12-08-2011 07:33 » 

RuNTiME, может вы целиком задачу опишите, а то разговор пошел на пустом месте)
задач много, способов реализации тоже) щас каждый выложит свои задачи многопоточности и соответствующие решения и будет каша)
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #44 : 12-08-2011 07:39 » 

darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество. А вот в случае неудачи захвата по любому придется ожидать.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
darkelf
Молодой специалист

ua
Offline Offline

« Ответ #45 : 12-08-2011 07:46 » 

darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество.
Про это я знаю.

А вот в случае неудачи захвата по любому придется ожидать.
В принципе, я про это и говорил, видимо мы друг-друга немного не поняли.
Записан
RuNTiME
Помогающий

ru
Offline Offline
Пол: Мужской

« Ответ #46 : 12-08-2011 07:55 » 

Ochkarik, На вопрос для которого создавалась эта тема я получил ответ, получил даже намного больше. Общая задача это написание библиотеки сильно упрощающей разработку Web приложений на C++. Это не производственная задача, пишу в своё удовольствие (так что сильно не пинайте).  Улыбаюсь Если кому - то это интересно, могу создать отдельную тему и можем обсудить целесообразность всего этого.
Записан

Любимая игрушка - debugger ...
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines