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. Да, тоже не без проблем, но — небо и земля.
Здравствуйте, Andrew S, Вы писали:
AS>>>Я за них всех очень рад. А вам посоветую просто посмотреть код ACE, благо он доступен. И сделать выводы. То, что я увидел там, привело меня к однозначному решению, которое я тут неоднократно озвучивал. С примерами. A>>Да видел я тот код — имел дело с TAO. Внутри выглядит кошмарно, не спорю. Ну и что с того? это проблемы авторов либы.
AS>Тогда непонятно откуда ваши вопросы
Оттого, наверное, что мне не важно как оно внутри сделано
AS>Согласитесь, странно использовать устройство, которое внешне выглядит как бронежилет, а на самом деле сделано из тряпочек заместо кевлара.
Вам ехать или шашечки?
AS>Или политика партии — сляпать абы как лишь бы работало?
Мне — лишь бы работало и совсем не интересно смотреть чужие исходники. Пусть авторы сами в своем огороде разбираются.
ACE — поддерживается? новые версии выпускают? баги исправляют? если "да" (не знаю, не слежу), значит все хорошо, можно пользовать.
Алексей
Re[10]: [Win32, VC8] CRITICAL_SECTION vs boost::mutex
AS>>>>Я за них всех очень рад. А вам посоветую просто посмотреть код ACE, благо он доступен. И сделать выводы. То, что я увидел там, привело меня к однозначному решению, которое я тут неоднократно озвучивал. С примерами. A>>>Да видел я тот код — имел дело с TAO. Внутри выглядит кошмарно, не спорю. Ну и что с того? это проблемы авторов либы.
AS>>Тогда непонятно откуда ваши вопросы A>Оттого, наверное, что мне не важно как оно внутри сделано
AS>>Согласитесь, странно использовать устройство, которое внешне выглядит как бронежилет, а на самом деле сделано из тряпочек заместо кевлара. A>Вам ехать или шашечки?
В данном контексте этот вопрос неуместен.
AS>>Или политика партии — сляпать абы как лишь бы работало? A>Мне — лишь бы работало и совсем не интересно смотреть чужие исходники. Пусть авторы сами в своем огороде разбираются.
Вот так и рождаются пользователи "г@@@о-кода". В частности, добавляются в список пользователей ACE/TAO. Видимо, вот и ответ на ваш первоначальный вопрос.
A>ACE — поддерживается? новые версии выпускают? баги исправляют? если "да" (не знаю, не слежу), значит все хорошо, можно пользовать.
На этом нашу с вами беседу можно считать оконченой. Удачи с таким подходом, к сожалению, пожелать не могу.
Здравствуйте, Alexander G, Вы писали:
AG>Если на CRITICAL_SECTION происходит конкуренция (и спинлок, если он есть, не срабатывает), создаётся событие (если оно ещё не создано). Если на boost::mutex конкуренции, событие не создаётся. Т.о. boost::mutex и есть реализация КС.
В boost::mutex тоже создаётся объект ядра для ожидания.
Здравствуйте, Andrew S, Вы писали:
AG>>Лучше всего было бы довести mutex до того, чтобы он был эффективнее КС:
AS>Не лучше. Системные примитивы могут реализовываться совершенно специфическими способами, учитывающими как заморочки шедуллера, так и менеджера объектов. В общем, так, как сделано сейчас в бусте — это не путь джедая.
Скорость для мьютекса имеет смысл только на быстром пути, когда не происходит блокировки в ядре. А тут никакой шедулер и менеджера объектов (кстати что это такое?) не имеет никакого влияния. Имеет влияние только выполнится 20 инструкций + вызов функции, или выполнится только 5 инструкций без вызовов функций. Поэтому boost::mutex в идеале бесспорно быстрее CRITICAL_SECTION, просто Anthony Williams немного облажался.
AS>На мой взгляд, правильный подход — делать обобщенную обертку, которая в случае наличия системного примитива пользует его, иначе — собственная реализация. Банальные таблицы подстановки решают это крайне эффективно, более того, можно для разных систем определить приоритеты использования в зависимости от производительности.
Там требования были более требовательные. Во-первых, мьютекс должен уметь статически инициализироваться, а-ля PTHREAD_MUTEX_INITIALIZER, что может быть чрезвычайно критично в некоторых контекстах. Во-вторых, должно быть ожидание с тайм-аутом. Ни того, ни другого CRITICAL_SECTION не предоставляет.
AG>>Можно не платить за SpinLock и DebugInfo, если ими не пользуемся. Можно не кидать SEH. Когда попытка залочить свободный мьютекс будет помещаться в несколько инструкций, инлайнить это дело.
AS>См. выше.
AG>>>Лучше всего было бы довести mutex до того, чтобы он был эффективнее КС:
AS>>Не лучше. Системные примитивы могут реализовываться совершенно специфическими способами, учитывающими как заморочки шедуллера, так и менеджера объектов. В общем, так, как сделано сейчас в бусте — это не путь джедая.
R>Скорость для мьютекса имеет смысл только на быстром пути, когда не происходит блокировки в ядре. А тут никакой шедулер и менеджера объектов (кстати что это такое?) не имеет никакого влияния. Имеет влияние только выполнится 20 инструкций + вызов функции, или выполнится только 5 инструкций без вызовов функций. Поэтому boost::mutex в идеале бесспорно быстрее CRITICAL_SECTION, просто Anthony Williams немного облажался.
Неверно. Для однопроцессорного hal критическая секция может быть реализована куда как эффективнее. В общем, не все так просто, как кажется.
AS>>На мой взгляд, правильный подход — делать обобщенную обертку, которая в случае наличия системного примитива пользует его, иначе — собственная реализация. Банальные таблицы подстановки решают это крайне эффективно, более того, можно для разных систем определить приоритеты использования в зависимости от производительности.
R>Там требования были более требовательные. Во-первых, мьютекс должен уметь статически инициализироваться, а-ля PTHREAD_MUTEX_INITIALIZER, что может быть чрезвычайно критично в некоторых контекстах. Во-вторых, должно быть ожидание с тайм-аутом. Ни того, ни другого CRITICAL_SECTION не предоставляет.
А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
Здравствуйте, Andrew S, Вы писали:
AS>Неверно. Для однопроцессорного hal критическая секция может быть реализована куда как эффективнее. В общем, не все так просто, как кажется.
Можно подробнее ?
Дело в том что процитированный мной ассемблерный код был получен с однопроцессорной машины. Или где и как я могу смотреть случай однопроцессорного hal ?
Обсуждение эффективности блокирования на КС не так интересно как эффективность лучшего случая. Если происходит постоянное блокирование потоков на КС, значит использование этих КС и потоков провалено.
Можно провести аналогию с производительностью исключений — обсуждается производительность случаев при отсутсвии исключений, при наличии исключений интересует корректность, за производительностью не гонятся. И логика нормальной работы не должна строиться на исключениях.
Здравствуйте, Andrew S, Вы писали:
AG>>>>Лучше всего было бы довести mutex до того, чтобы он был эффективнее КС:
AS>>>Не лучше. Системные примитивы могут реализовываться совершенно специфическими способами, учитывающими как заморочки шедуллера, так и менеджера объектов. В общем, так, как сделано сейчас в бусте — это не путь джедая.
R>>Скорость для мьютекса имеет смысл только на быстром пути, когда не происходит блокировки в ядре. А тут никакой шедулер и менеджера объектов (кстати что это такое?) не имеет никакого влияния. Имеет влияние только выполнится 20 инструкций + вызов функции, или выполнится только 5 инструкций без вызовов функций. Поэтому boost::mutex в идеале бесспорно быстрее CRITICAL_SECTION, просто Anthony Williams немного облажался.
AS>Неверно. Для однопроцессорного hal критическая секция может быть реализована куда как эффективнее. В общем, не все так просто, как кажется.
Это единственный момент?
Если да, то в чём проблема проделать тоже самое в своей реализации? Этот трюк применялся ещё в ACE.
Вообще моё лично мнение по-поводу этого приёма, что сейчас уже не стоит его использовать. Имхо лучше получить хороший заинлайненый код для современных процессоров, чем выграть на старых процессорах.
А вот как избавляться от вызова функции, и от DEBUG_INFO, и от рекурсивности (читай — обращения к TLS и дополнительных инструкций и ветвлений) в случае CRITICAL_SECTION? Вот это для меня пока загадка...
AS>>>На мой взгляд, правильный подход — делать обобщенную обертку, которая в случае наличия системного примитива пользует его, иначе — собственная реализация. Банальные таблицы подстановки решают это крайне эффективно, более того, можно для разных систем определить приоритеты использования в зависимости от производительности.
R>>Там требования были более требовательные. Во-первых, мьютекс должен уметь статически инициализироваться, а-ля PTHREAD_MUTEX_INITIALIZER, что может быть чрезвычайно критично в некоторых контекстах. Во-вторых, должно быть ожидание с тайм-аутом. Ни того, ни другого CRITICAL_SECTION не предоставляет.
AS>А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
Я прочитал ещё и раз и опять вижу, что другое. Поясни, пожалуйста.
По-крайней мере я могу сделать вывод, что CRITICAL_SECTION никогда не будет использоваться в замен собственной реализации в boost, т.к. не удовлетворяет всем требованиям.
AS>>А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
R>Я прочитал ещё и раз и опять вижу, что другое. Поясни, пожалуйста. R>По-крайней мере я могу сделать вывод, что CRITICAL_SECTION никогда не будет использоваться в замен собственной реализации в boost, т.к. не удовлетворяет всем требованиям.
Еще раз. Я не предлагаю _заменить_ mutex буста. Я предлагаю сделать новый неймспейс примитивов синхронизации, которые будут реализованы посредством системы. Да, они будут обладать многими ограничениями, но в очень многих случаях то, что предлагает самобустовский мьютекс, просто не нужно.
По поводу производительности критической секции — это проблемы ОС, и как будет в новых версиях оно работать, мы не можем предположить. Например, тот же самый мьютекс может выделяться из пула и отдаваться туда по ненужности — в общем, возможно _очень_ много системных оптимизаций, которые зависят от внутренностей системы. Внешняя либа просто не может знать всей кухни для каждой системы.
Здравствуйте, Andrew S, Вы писали:
AS>>>А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
R>>Я прочитал ещё и раз и опять вижу, что другое. Поясни, пожалуйста. R>>По-крайней мере я могу сделать вывод, что CRITICAL_SECTION никогда не будет использоваться в замен собственной реализации в boost, т.к. не удовлетворяет всем требованиям.
AS>Еще раз. Я не предлагаю _заменить_ mutex буста. Я предлагаю сделать новый неймспейс примитивов синхронизации, которые будут реализованы посредством системы. Да, они будут обладать многими ограничениями, но в очень многих случаях то, что предлагает самобустовский мьютекс, просто не нужно.
Во-первых, а смысл этого? Какие приемущества? Кроме того, что системный мьютекс медленнее, не обладаем рядом возможностей и непредсказуем.
Я тебя уверяю, что PTHREAD_MUTEX_INITIALIZER добавлен в POSIX отнюдь не ради развлечения.
AS>По поводу производительности критической секции — это проблемы ОС, и как будет в новых версиях оно работать, мы не можем предположить. Например, тот же самый мьютекс может выделяться из пула и отдаваться туда по ненужности — в общем, возможно _очень_ много системных оптимизаций, которые зависят от внутренностей системы. Внешняя либа просто не может знать всей кухни для каждой системы.
Пул для объектов в 16 байт, которые обычно встроены в другие объекты? Это смешно.
Приведи хотя бы несколько из этих _многих_ оптимизаций.
Здравствуйте, remark, Вы писали:
AG>>Если на CRITICAL_SECTION происходит конкуренция (и спинлок, если он есть, не срабатывает), создаётся событие (если оно ещё не создано). Если на boost::mutex конкуренции, событие не создаётся. Т.о. boost::mutex и есть реализация КС.
R>В boost::mutex тоже создаётся объект ядра для ожидания.
Ну да, я имел в виду >Если на boost::mutex конкуренции нет, событие не создаётся.
Мне другое интересно.
Выяснено что вместо пяти инструкций на начало boost::mutex::lock их куча, т.к.
1. создаётся объект ::boost::detail::get_system_time_sentinel().
2. он же копируется.
3. код после потытки lock bts не вынесен отдельно, в результате lock bts не встраивается.
Неужели это не проблема ?
Судя по обсуждению в boost.users, разработчик считает проблемой:
1. Автолинковка на либу Thread
2. Автолинковка на либу Date-time
3. Включение <windows.h>
Какая в этом проблема ?
AS>>>>А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
R>>>Я прочитал ещё и раз и опять вижу, что другое. Поясни, пожалуйста. R>>>По-крайней мере я могу сделать вывод, что CRITICAL_SECTION никогда не будет использоваться в замен собственной реализации в boost, т.к. не удовлетворяет всем требованиям.
AS>>Еще раз. Я не предлагаю _заменить_ mutex буста. Я предлагаю сделать новый неймспейс примитивов синхронизации, которые будут реализованы посредством системы. Да, они будут обладать многими ограничениями, но в очень многих случаях то, что предлагает самобустовский мьютекс, просто не нужно.
R>Во-первых, а смысл этого? Какие приемущества? Кроме того, что системный мьютекс медленнее, не обладаем рядом возможностей и непредсказуем. R>Я тебя уверяю, что PTHREAD_MUTEX_INITIALIZER добавлен в POSIX отнюдь не ради развлечения.
Системный мьютекс может быть быстрее. Все, честно, я устал. Перечитай, что я пишу.
AS>>По поводу производительности критической секции — это проблемы ОС, и как будет в новых версиях оно работать, мы не можем предположить. Например, тот же самый мьютекс может выделяться из пула и отдаваться туда по ненужности — в общем, возможно _очень_ много системных оптимизаций, которые зависят от внутренностей системы. Внешняя либа просто не может знать всей кухни для каждой системы.
R>Пул для объектов в 16 байт, которые обычно встроены в другие объекты? Это смешно. R>Приведи хотя бы несколько из этих _многих_ оптимизаций.
Я про эвент, который используется для ожидания. Ты того.. не тормози
AS>>Неверно. Для однопроцессорного hal критическая секция может быть реализована куда как эффективнее. В общем, не все так просто, как кажется.
AG>Можно подробнее ? AG>Дело в том что процитированный мной ассемблерный код был получен с однопроцессорной машины. Или где и как я могу смотреть случай однопроцессорного hal ?
Например, lock inc. Так вот, на однопроцессорной машине эта тяжелая инструкция не нужна, можно просто inc обойтись. А иначе это занимают бОльшую часть основного сценария.
AG>Обсуждение эффективности блокирования на КС не так интересно как эффективность лучшего случая. Если происходит постоянное блокирование потоков на КС, значит использование этих КС и потоков провалено.
Здравствуйте, Andrew S, Вы писали:
AS>>>>>А я разве говорю нечто другое? Прочитай внимательнее, о чем речь
R>>>>Я прочитал ещё и раз и опять вижу, что другое. Поясни, пожалуйста. R>>>>По-крайней мере я могу сделать вывод, что CRITICAL_SECTION никогда не будет использоваться в замен собственной реализации в boost, т.к. не удовлетворяет всем требованиям.
AS>>>Еще раз. Я не предлагаю _заменить_ mutex буста. Я предлагаю сделать новый неймспейс примитивов синхронизации, которые будут реализованы посредством системы. Да, они будут обладать многими ограничениями, но в очень многих случаях то, что предлагает самобустовский мьютекс, просто не нужно.
R>>Во-первых, а смысл этого? Какие приемущества? Кроме того, что системный мьютекс медленнее, не обладаем рядом возможностей и непредсказуем. R>>Я тебя уверяю, что PTHREAD_MUTEX_INITIALIZER добавлен в POSIX отнюдь не ради развлечения.
AS>Системный мьютекс может быть быстрее. Все, честно, я устал. Перечитай, что я пишу.
Естественно он может быть быстрее, если мы плохо реализуем свой.
Но в тоже время мы всегда можем реализовать свой быстрее, чем системный. Т.к. как минимум мы можем сделать встраиваемую функцию. А что может сделать системный мьютекс такого, чего не можем мы, я по прежнему не вижу. Ты говоришь, что этого _много_. Но я пока не вижу ни одного пункта.
AS>>>По поводу производительности критической секции — это проблемы ОС, и как будет в новых версиях оно работать, мы не можем предположить. Например, тот же самый мьютекс может выделяться из пула и отдаваться туда по ненужности — в общем, возможно _очень_ много системных оптимизаций, которые зависят от внутренностей системы. Внешняя либа просто не может знать всей кухни для каждой системы.
R>>Пул для объектов в 16 байт, которые обычно встроены в другие объекты? Это смешно. R>>Приведи хотя бы несколько из этих _многих_ оптимизаций.
AS>Я про эвент, который используется для ожидания. Ты того.. не тормози
Ммм.. А что нам мешает его кэшировать? Мы сами кстати опять же можем это сделать значительно быстрее. Т.к. нам не надо будет делать системные вызовы для возращения/получения из пула.
Здравствуйте, Andrew S, Вы писали:
AS>>>Неверно. Для однопроцессорного hal критическая секция может быть реализована куда как эффективнее. В общем, не все так просто, как кажется.
AG>>Можно подробнее ? AG>>Дело в том что процитированный мной ассемблерный код был получен с однопроцессорной машины. Или где и как я могу смотреть случай однопроцессорного hal ?
AS>Например, lock inc. Так вот, на однопроцессорной машине эта тяжелая инструкция не нужна, можно просто inc обойтись. А иначе это занимают бОльшую часть основного сценария.
Здравствуйте, Andrew S, Вы писали:
AS>Например, lock inc. Так вот, на однопроцессорной машине эта тяжелая инструкция не нужна, можно просто inc обойтись. А иначе это занимают бОльшую часть основного сценария.
Да, я понял. Но я цитировал код EnterCriticalSection с однопроцессорной машины. Т.е. да, КС могла бы быть реализована без этого lock inc. (Windows XP SP2, процессор — Celeron какой-то).
Зачем зависить на API, где "теоретичкски в следующей версии могут сделать как надо", если можно самостоятельно сделать как надо ?
AS>>Например, lock inc. Так вот, на однопроцессорной машине эта тяжелая инструкция не нужна, можно просто inc обойтись. А иначе это занимают бОльшую часть основного сценария.
AG>Да, я понял. Но я цитировал код EnterCriticalSection с однопроцессорной машины. Т.е. да, КС могла бы быть реализована без этого lock inc. (Windows XP SP2, процессор — Celeron какой-то).
AG>Зачем зависить на API, где "теоретичкски в следующей версии могут сделать как надо", если можно самостоятельно сделать как надо ?
Я уже устал это повторять — потому что в следующей версии появится, например, поддержка новых инструкций процессора, где есть не только RW барьеры.
Самостоятельно сделать "как надо" — просто не получится ввиду большого разнообразия внутренностей системы. А уж как пишут бустовцы под win — это, собственно, вообще потеха. В общем, не стОит считать себя умнее разработчиков системы, имхо.
Перекуём баги на фичи!
В этом случае да — ACE самое то 
Вот так и рождаются пользователи "г@@@о-кода". В частности, добавляются в список пользователей ACE/TAO. Видимо, вот и ответ на ваш первоначальный вопрос.
