AG>>Что лучше: CRITICAL_SECTION или boost::mutex (как он реализован в текущей версии для win32, vc8) ?
S>Удобнее своя обертка над CRITICAL_SECTION. Потому что boost::mutex в версии 1.36 довольно-таки тяжелый, и, что тоже неприятно, нерекурсивный.
Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)? Может, не так все плохо, как выглядит? А по поводу рекурсивности — есть мнение, что если она требуется, то имеет смысл пересмотреть стратегию синхронизации. И очень часто на практике так оно и есть...
Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
Здравствуйте, Andrew S, Вы писали:
AS>Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)? Может, не так все плохо, как выглядит?
Именно это и интересует. Сам сравнивать ещё не пробовал, интересуют любые мнения по поводу сравнения.
AS>А по поводу рекурсивности — есть мнение, что если она требуется, то имеет смысл пересмотреть стратегию синхронизации. И очень часто на практике так оно и есть...
По поводу рекурсивности, не понятно в чём вопрос. Есть boost::recursive_mutex.
AS>Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
IMHO.
Для написания обёртки над CRITICAL_SECTION следует решить следующие платформенные вопросы:
0. Какие версии Windows интересуют ? (Если вдруг интересует win9x, что тогда делать с TryEnterCriticalSection ?)
1. Что делать с SEH исключениями, кидаемыми из InitializeCriticalSectionXxx и EnterCriticalSection ?
2. Нужен ли конструктор, принимающий dwSpinCount ? Сколько dwSpinCount по дефлоту ?
3. Стоит ли в Vista передавать флаг CRITICAL_SECTION_NO_DEBUG_INFO ?
Когда эти вопросы решены, заимплементить интерфейс boost::recursive_mutex (т.е. Lockable concept) на основе CRITICAL_SECTION тривиально.
Другие лёгкие примитивы появились только в Vista, поэтому пока ещё не очень интересны.
Ну и если окажется что Boost.Thread лучше, то вообще не интересны
Что касается тяжелых примитивов, то там ещё больше платформенных вопросов, т.к. они более чем средства синхронизации нитей, это IPC. Также плохо себе представляю Lock, учитывающий разнообразия всяких CoWaitForMultipleHandles, MsgWaitForMultipleObjectsEx, etc.
Русский военный корабль идёт ко дну!
Re[3]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
> S>Удобнее своя обертка над CRITICAL_SECTION. Потому что boost::mutex в версии 1.36 довольно-таки тяжелый, и, что тоже неприятно, нерекурсивный. > > Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)? Может, не так все плохо, как выглядит?
Объект ядра (событие) против критической секции — иногда уже чересчур тяжело.
> А по поводу рекурсивности — есть мнение, что если она требуется, то имеет смысл пересмотреть стратегию синхронизации. И очень часто на практике так оно и есть...
Если бы так обстояло всегда, то, очевидно, boost::recursive_mutex не потребовался бы. Однако он есть
> Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
Вообще-то там есть lightweight_mutex, под win32 и pthreads, но он (пока) в detail живет.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[2]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
Здравствуйте, Sergey, Вы писали:
S>Удобнее своя обертка над CRITICAL_SECTION.
Если говорить про обёртки, то удобнее всё-таки не велосипед писать, а взять ATL+WTL. Там этих обёрток навалом.
S> Потому что boost::mutex в версии 1.36 довольно-таки тяжелый, и, что тоже неприятно, нерекурсивный.
boost::recursive_mutex ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Перекуём баги на фичи!
Re[3]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
Здравствуйте, Andrew S, Вы писали:
AS>Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)?
Буст удобнее — если не требуется спускаться на достаточно низкий уровень (например, жонглировать приоритетами потоков).
А жонглировать иногда нужно.
AS> Может, не так все плохо, как выглядит? А по поводу рекурсивности — есть мнение, что если она требуется, то имеет смысл пересмотреть стратегию синхронизации. И очень часто на практике так оно и есть...
Четыремя ногами за.
Скудость правильных средств заставляет думать о правильной архитектуре. Абы каких средств — изобретать велосипед. (Это я про буст и винапи соответственно).
AS>Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
Не айс? (ACE framework) ?
Впрочем, лично я с айсом дела не имел — только всячески наслышан.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Перекуём баги на фичи!
Re[4]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
Здравствуйте, Sergey, Вы писали:
>> Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)? Может, не так все плохо, как выглядит?
S>Объект ядра (событие) против критической секции — иногда уже чересчур тяжело.
Если на CRITICAL_SECTION происходит конкуренция (и спинлок, если он есть, не срабатывает), создаётся событие (если оно ещё не создано). Если на boost::mutex конкуренции, событие не создаётся. Т.о. boost::mutex и есть реализация КС.
Сабжевый вопрос про преимущества/недостатки этой реализации.
S>Если бы так обстояло всегда, то, очевидно, boost::recursive_mutex не потребовался бы. Однако он есть
Всё таки, чем меньше вхождений в КС, тем меньше возможностей дедлока (классический дедлок — две нити входят в две КС в разных порядках). Повторное вхождение — оно ж лишнее, возможно означающее, что вхождения в КС не контролируются
>> Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
S>Вообще-то там есть lightweight_mutex, под win32 и pthreads, но он (пока) в detail живет.
Мы точно обсуждаем текущую версию, релиз 1.36 ?
Или Вы собрали из текущего SVN или, наоборот, откопали древнюю версию ?
Русский военный корабль идёт ко дну!
Re[5]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
>>> Кстати, интересно, а кто-нибудь пробовал сравнивать поделия boost::thread в части синхронизации c оными же, реализуемыми силами операционной системы (win32 5.1-6.0)? Может, не так все плохо, как выглядит? > > S>Объект ядра (событие) против критической секции — иногда уже чересчур тяжело. > > Если на CRITICAL_SECTION происходит конкуренция (и спинлок, если он есть, не срабатывает), создаётся событие (если оно ещё не создано).
> Если на boost::mutex конкуренции, событие не создаётся. Т.о. boost::mutex и есть реализация КС.
Да, слона то я и не заметил...
> Сабжевый вопрос про преимущества/недостатки этой реализации. > > S>Если бы так обстояло всегда, то, очевидно, boost::recursive_mutex не потребовался бы. Однако он есть > > Всё таки, чем меньше вхождений в КС, тем меньше возможностей дедлока (классический дедлок — две нити входят в две КС в разных порядках). Повторное вхождение — оно ж лишнее, возможно означающее, что вхождения в КС не контролируются
Лениво мне на эту тему флеймить, но случаи всякие бывают.
>>> Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле... > > S>Вообще-то там есть lightweight_mutex, под win32 и pthreads, но он (пока) в detail живет. > > Мы точно обсуждаем текущую версию, релиз 1.36 ? > Или Вы собрали из текущего SVN или, наоборот, откопали древнюю версию ?
Именно в текущей, 1.36 версии критические секции используются в:
1) asio::detail::win_mutex
2) boost::detail::lightweight_mutex
3) boost::details::pool:win32_mutex
Я имел в виду пункт 2 — boost::detail::lightweight_mutex.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[5]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
> S>Объект ядра (событие) против критической секции — иногда уже чересчур тяжело. > > Я на днях смотрел в исходники boost::mutex (правда в 1.34). Там вроде под Win32 на CRITICAL_SECTION основано. Мож конечно не совсем туда смотрел
В 1.36 переделали
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
К>Четыремя ногами за. К>Скудость правильных средств заставляет думать о правильной архитектуре. Абы каких средств — изобретать велосипед. (Это я про буст и винапи соответственно).
AS>>Вообще, конечно, очень не хватает в бусте оберток над системными примитивами. И пофиг, что в этом случае точки прерывания не будут работать, на самом деле...
К>Не айс? (ACE framework) ? К>Впрочем, лично я с айсом дела не имел — только всячески наслышан.
А я вот имел. Ощущения тут уже писАл, с примерами кучи проблем в одном компоненте. Более этого видеть не хочу. По моему глубокому убеждению (я пытался несколько раз себя заставить использовать это в разных проектах), ACE — очень _непрофессиональная_поделка_.
Я не думаю, что в этом есть смысл, по крайней мере до того момента, как на суд общественности будут представлены сравнительные тесты производительности. Как синтетика, так и общие паттерны. А до того момента все, что можно сделать — тупо сравнить нагенеренный для буста код с кодом критической секции, и сделать выводы. В случае vc9, имхо, особо большой разницы за счет интринсиков не будет, так что в общем то, это тоже будет "ниочём".
В общем, тесты нужны, тесты. А лучше всего — кроме mutex иметь еще sys_thread_mutex, который будет иметь ограниченную функциональность, но использовать примитивы операционной системы. Тогда и не будет возникать проблем — хочется расширенной функциональности — пользуй mutex (кстати, называться на самом деле он должен thread_mutex, ну да ладно). Хочется производительности — пользуй системный. И все шоколадно.
Здравствуйте, Andrew S, Вы писали:
AS>А я вот имел. Ощущения тут уже писАл, с примерами кучи проблем в одном компоненте. Более этого видеть не хочу. По моему глубокому убеждению (я пытался несколько раз себя заставить использовать это в разных проектах), ACE — очень _непрофессиональная_поделка_. http://www.cs.wustl.edu/~schmidt/ACE-users.html:
ACE+TAO are being used in the displays subsystem of Raytheon's Ship Self-Defense System (SSDS MK2) on the USS Ronald Reagan aircraft carrier.
Или врут? или вы просто не в те проекты пытались ACE пристроить?
Здравствуйте, Andrew S, Вы писали:
AS>А до того момента все, что можно сделать — тупо сравнить нагенеренный для буста код с кодом критической секции, и сделать выводы. В случае vc9, имхо, особо большой разницы за счет интринсиков не будет, так что в общем то, это тоже будет "ниочём".
Уже попробовал для случая отсутсвия многопоточности. Подозревал, что boost::mutex может даже обогнать за счёт отсутствия (часто неиспользуемого) спинлока и наличия инлайнинга.
Однако, код КС лучше. Результат подтверждается тестом.
В boost::mutex создаётся временный ::boost::detail::get_system_time_sentinel() на каждый lock, т.к. lock реализован на timed_lock (типа, вылить воду из чайника и свести задачу к предыдущей). И много кода после попытки залочить через lock bts, так что lock не инлайнится.
В общем boost::mutex мог бы быть лучше для этого случая, если бы он был специально оптимизирован, а так — КС лучше.
AS>В общем, тесты нужны, тесты. А лучше всего — кроме mutex иметь еще sys_thread_mutex, который будет иметь ограниченную функциональность, но использовать примитивы операционной системы. Тогда и не будет возникать проблем — хочется расширенной функциональности — пользуй mutex (кстати, называться на самом деле он должен thread_mutex, ну да ладно). Хочется производительности — пользуй системный. И все шоколадно.
Лучше всего было бы довести mutex до того, чтобы он был эффективнее КС:
Можно не платить за SpinLock и DebugInfo, если ими не пользуемся. Можно не кидать SEH. Когда попытка залочить свободный мьютекс будет помещаться в несколько инструкций, инлайнить это дело.
Русский военный корабль идёт ко дну!
Re[6]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
AS>>А я вот имел. Ощущения тут уже писАл, с примерами кучи проблем в одном компоненте. Более этого видеть не хочу. По моему глубокому убеждению (я пытался несколько раз себя заставить использовать это в разных проектах), ACE — очень _непрофессиональная_поделка_. A>http://www.cs.wustl.edu/~schmidt/ACE-users.html: A>
A>ACE+TAO are being used in the displays subsystem of Raytheon's Ship Self-Defense System (SSDS MK2) on the USS Ronald Reagan aircraft carrier.
A>Или врут? или вы просто не в те проекты пытались ACE пристроить?
Я за них всех очень рад. А вам посоветую просто посмотреть код ACE, благо он доступен. И сделать выводы. То, что я увидел там, привело меня к однозначному решению, которое я тут неоднократно озвучивал. С примерами.
AG>В boost::mutex создаётся временный ::boost::detail::get_system_time_sentinel() на каждый lock, т.к. lock реализован на timed_lock (типа, вылить воду из чайника и свести задачу к предыдущей). И много кода после попытки залочить через lock bts, так что lock не инлайнится. AG>В общем boost::mutex мог бы быть лучше для этого случая, если бы он был специально оптимизирован, а так — КС лучше.
AS>>В общем, тесты нужны, тесты. А лучше всего — кроме mutex иметь еще sys_thread_mutex, который будет иметь ограниченную функциональность, но использовать примитивы операционной системы. Тогда и не будет возникать проблем — хочется расширенной функциональности — пользуй mutex (кстати, называться на самом деле он должен thread_mutex, ну да ладно). Хочется производительности — пользуй системный. И все шоколадно.
AG>Лучше всего было бы довести mutex до того, чтобы он был эффективнее КС:
Не лучше. Системные примитивы могут реализовываться совершенно специфическими способами, учитывающими как заморочки шедуллера, так и менеджера объектов. В общем, так, как сделано сейчас в бусте — это не путь джедая.
На мой взгляд, правильный подход — делать обобщенную обертку, которая в случае наличия системного примитива пользует его, иначе — собственная реализация. Банальные таблицы подстановки решают это крайне эффективно, более того, можно для разных систем определить приоритеты использования в зависимости от производительности.
AG>Можно не платить за SpinLock и DebugInfo, если ими не пользуемся. Можно не кидать SEH. Когда попытка залочить свободный мьютекс будет помещаться в несколько инструкций, инлайнить это дело.
Здравствуйте, Andrew S, Вы писали:
AS>>>А я вот имел. Ощущения тут уже писАл, с примерами кучи проблем в одном компоненте. Более этого видеть не хочу. По моему глубокому убеждению (я пытался несколько раз себя заставить использовать это в разных проектах), ACE — очень _непрофессиональная_поделка_. A>>http://www.cs.wustl.edu/~schmidt/ACE-users.html: A>>
A>>ACE+TAO are being used in the displays subsystem of Raytheon's Ship Self-Defense System (SSDS MK2) on the USS Ronald Reagan aircraft carrier.
A>>Или врут? или вы просто не в те проекты пытались ACE пристроить?
AS>Я за них всех очень рад. А вам посоветую просто посмотреть код ACE, благо он доступен. И сделать выводы. То, что я увидел там, привело меня к однозначному решению, которое я тут неоднократно озвучивал. С примерами.
Да видел я тот код — имел дело с TAO. Внутри выглядит кошмарно, не спорю. Ну и что с того? это проблемы авторов либы.
Алексей
Re[8]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
AS>>Я за них всех очень рад. А вам посоветую просто посмотреть код ACE, благо он доступен. И сделать выводы. То, что я увидел там, привело меня к однозначному решению, которое я тут неоднократно озвучивал. С примерами. A>Да видел я тот код — имел дело с TAO. Внутри выглядит кошмарно, не спорю. Ну и что с того? это проблемы авторов либы.
Тогда непонятно откуда ваши вопросы Согласитесь, странно использовать устройство, которое внешне выглядит как бронежилет, а на самом деле сделано из тряпочек заместо кевлара. Или политика партии — сляпать абы как лишь бы работало? В этом случае да — ACE самое то И не надо опять тягомотины что вот бесплатно и т.д. — посмотрите ту же POCO или stlsoft. Да, тоже не без проблем, но — небо и земля.
Перекуём баги на фичи!
В этом случае да — ACE самое то 