PredatorAlpha
Помогающий
 Offline
|
 |
« Ответ #30 : 11-08-2011 12:15 » |
|
Там используется то, что деструкторы локальных объектов вызываются в любом случае, даже если return где-то в теле или возникло исключение. Очень удобная штука для освобождения ресурсов.
Просто Ochkarik больше на классическом С работает...
|
|
|
|
|
Записан
|
|
|
|
|
Ochkarik
|
|
« Ответ #31 : 11-08-2011 12:20 » |
|
а в каком месте та переменная то стоит, которую синхронизировать надо было?
|
|
|
|
|
Записан
|
RTFM уже хоть раз наконец!  :[ ну или хотя бы STFW...
|
|
|
|
RuNTiME
|
|
« Ответ #32 : 11-08-2011 12:24 » |
|
Ochkarik, Тут просто пояснение почему и как работает MutexLocker. Переменную смотри в начале, где я выкладывал код класса Thread.
|
|
|
|
|
Записан
|
Любимая игрушка - debugger ...
|
|
|
|
Ochkarik
|
|
« Ответ #33 : 11-08-2011 14:17 »  |
|
я просто за основной алгоритм принял фразу: "Есть переменная, тип int. Два потока пишут в эту переменную, а третий считывает значение этой переменной." и для этого - функции ожидания не нужны. а на самом деле, вам еще и функции ожидания была жизненно необходима? Просто Ochkarik больше на классическом С работает...
есть немного)))) |
|
|
|
« Последнее редактирование: 11-08-2011 14:26 от Ochkarik »
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
PredatorAlpha
Помогающий
Offline
|
|
« Ответ #34 : 11-08-2011 14:36 » |
|
Просто Ochkarik больше на классическом С работает...
есть немного)))) Я сам такой... Embedded-программер.. |
|
|
|
|
Записан
|
|
|
|
|
RuNTiME
|
|
« Ответ #35 : 11-08-2011 15:36 » |
|
Ochkarik, а на самом деле, вам еще и функции ожидания была жизненно необходима? Изначально мне нужно было только лишь узнать, можно ли безопасно считывать значение этой самой переменной. И я сформулировал только суть. Ну, а раз уж тему развили, почему бы и не по обсуждать связанные с этим проблемы... 
|
|
|
|
|
Записан
|
Любимая игрушка - debugger ...
|
|
|
|
Ochkarik
|
|
« Ответ #36 : 11-08-2011 15:46 » |
|
тады - ой)
|
|
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
|
Антон (LogRus)
|
|
« Ответ #37 : 12-08-2011 04:22 » |
|
ну и очередные мои 5 копеек lock не блокирует шину, времена те давно минули lock блокирует кэш линию пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые? PPS: а сравнительные тесты будут? PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса |
|
|
|
|
Записан
|
Странно всё это....
|
|
|
darkelf
Молодой специалист
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)
|
|
« Ответ #39 : 12-08-2011 05:39 » |
|
darkelf, что-то я про это совсем забыл вот я раздолбай, давно много потоковые системы не строил
|
|
|
|
|
Записан
|
Странно всё это....
|
|
|
|
RXL
|
|
« Ответ #40 : 12-08-2011 06:47 » |
|
пару раз упоминалось использование объектов ядра для синхронизации, но имхо в Париже так уже не носят обычно используется, то что называет futex, собственно реализация мьютекса с использованием асма и есть реализация futex, главный бонус это отсутсвие переключения контекста и отсутсвие объектов ядра, которые как известно имеют тенденцию кончаться в некоторых системах Собственно, расположив их в разделяемой памяти можно и межпроцессное взаимодействие осуществлять без участия ядра. Добавлено через 2 минуты и 45 секунд:darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика. |
|
|
|
« Последнее редактирование: 12-08-2011 06:50 от RXL »
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
|
RuNTiME
|
|
« Ответ #41 : 12-08-2011 07:01 » |
|
PS: а зачем тебе своя реализация всего этого чуда, если есть открытые и быстрые?
По двум причинам: Первая и основная углубленное изучение многопоточного программирования (ну хочется мне). А вторая банальная - свести к минимуму кол-во зависимостей. PPS: а сравнительные тесты будут?
Сравнивать пока нечего да и основные задачи библиотеки не реализация классов для написания многопоточных приложений. PPPS: кстати рекомендую использовать названия для классов и методов используемые в tbb и boost::thread - это позволит быстро менять реализацию блокировок в приложении или отдельном классе в зависимости от желания и модели использования конкретного класса
За наводку на tbb спасибо. Вчера еще скачал эту библиотеку. Будет с чего брать пример. boost - очень уж громоздок если использовать его только для запуска потоков |
|
|
|
|
Записан
|
Любимая игрушка - debugger ...
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #42 : 12-08-2011 07:28 » |
|
Добавлено через 2 минуты и 45 секунд:
darkelf, принцип простой: если не можешь захватить, то выполни yield() и потом еще раз попробуешь. Никаких дополнительных очередей - все в рамках обычного планировщика.
Imho, yield(), требует как входа в ядро, так и использования очереди - в случае, если есть более высокоприоритетные процессы/потоки текущий процесс надо будет приостановить, соответственно, поставить в очередь ожидания и выполнить переключение контекста на более приоритетный. |
|
|
|
|
Записан
|
|
|
|
|
Ochkarik
|
|
« Ответ #43 : 12-08-2011 07:33 » |
|
RuNTiME, может вы целиком задачу опишите, а то разговор пошел на пустом месте)
задач много, способов реализации тоже) щас каждый выложит свои задачи многопоточности и соответствующие решения и будет каша)
|
|
|
|
|
Записан
|
RTFM уже хоть раз наконец! :[ ну или хотя бы STFW...
|
|
|
|
RXL
|
|
« Ответ #44 : 12-08-2011 07:39 » |
|
darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество. А вот в случае неудачи захвата по любому придется ожидать.
|
|
|
|
|
Записан
|
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
darkelf
Молодой специалист
Offline
|
|
« Ответ #45 : 12-08-2011 07:46 » |
|
darkelf, для проверки и захвата мютекса входить в ядро не нужно - это и есть преимущество.
Про это я знаю. А вот в случае неудачи захвата по любому придется ожидать.
В принципе, я про это и говорил, видимо мы друг-друга немного не поняли. |
|
|
|
|
Записан
|
|
|
|
|
RuNTiME
|
|
« Ответ #46 : 12-08-2011 07:55 » |
|
Ochkarik, На вопрос для которого создавалась эта тема я получил ответ, получил даже намного больше. Общая задача это написание библиотеки сильно упрощающей разработку Web приложений на C++. Это не производственная задача, пишу в своё удовольствие (так что сильно не пинайте). Если кому - то это интересно, могу создать отдельную тему и можем обсудить целесообразность всего этого.
|
|
|
|
|
Записан
|
Любимая игрушка - debugger ...
|
|
|
|
