Здравствуйте, dead0k, Вы писали:
D>Здравствуйте, PowerUserX, Вы писали: PUX>> только cond_var
D>У которого есть wait_for/wait_until. D>Чего не хватает?
Быстро написал
имел ввиду что есть mutex b cond_var
а хотел бы event c методами типа wait b wait_time_for
Re[2]: В STL почему нет аналога Event Objects(Win32)
Спасибо за ссылки, стало понятнее, как на condition_variable эмулировать event.)
Но все равно осталось непонятным, почему кроссплатформенные библиотеки не реализуют такой удобный примитив синхронизации, как event: первая Ваша ссылка очень наглядно демонстрирует, насколько код с event проще и понятнее.) В чем именно состоят идеологические дефекты event'а? Подозреваю, что stl, QT и другие кроссплатформенные библиотеки не используют аналога виндового события потому, что на юниксе его сложно реализовать.)
Здравствуйте, PowerUserX, Вы писали:
PUX>Почему В STL почему нет аналога Event Objects(Win32)?
ИМХО потому что нет реализации в ядре систем, на которые пришлось все же ориентироваться.
Contrary to popular belief, event objects – a construct particular to MS Windows and not found in *NIX OS:es – are useful in many instances where exact thread execution control is needed. For instance, you may want to have a thread pausing itself while starting another one.
However, if you post a question on a *NIX forum about how to implement event objects or something similar, you will likely get an answer along the lines of “just use mutexes”. Unfortunately, there is no “just” about it. Implementing event objects is a bit tricky, as there are several instances where race conditions or deadlocks can occur.
Кстати, в ядре Windows есть еще специальный объект EventPair, для которого можно атомарно дождаться одного ивента пары и установить другой ивент, но в Win API он не экспонируется, только через ntdll.dll
Здравствуйте, jahr, Вы писали:
J>В чем именно состоят идеологические дефекты event'а? Подозреваю, что stl, QT и другие кроссплатформенные библиотеки не используют аналога виндового события потому, что на юниксе его сложно реализовать.)
я бы предположил, что связка cond_var + mutex более мощная, нежели Event. последний может быть реализован с помощью первых двух
так что с реализацией на линуксе проблем не будет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Implementing event objects is a bit tricky, as there are several instances where race conditions or deadlocks can occur. PD>http://win32eoposix.sourceforge.net/
тут основная сложность в реализации WaitForMultipleObjects, которая далеко не всегда нужна. без нее все должно быть просто (по прикидкам)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, PowerUserX, Вы писали:
PUX>>Почему В STL почему нет аналога Event Objects(Win32)?
PD>ИМХО потому что нет реализации в ядре систем, на которые пришлось все же ориентироваться.
CCore замечательно работает и поверх Windows, и поверх Linux.
Здравствуйте, Шахтер, Вы писали:
Ш>CCore замечательно работает и поверх Windows, и поверх Linux.
Ну и что ? Посмотри ссылку, которую я привел, там как раз моделирование ивентов с помощью мютексов. Я же не говорю, что сделать нельзя. Я просто думаю, что в виду того, что ивенты ядром линукса не поддерживаются, авторы STL решили их не включать. Моделируйте сами как хотите.
With best regards
Pavel Dvorkin
Re[2]: В STL почему нет аналога Event Objects(Win32)
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, PowerUserX, Вы писали:
CS>Наверное потому что такой примитив добавить тривиально можно, как-то так:
CS>
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, PowerUserX, Вы писали:
CS>Наверное потому что такой примитив добавить тривиально можно
можно
CS>как-то так
ну далековато от истины. лучше см. код B0FEE664
Re[2]: В STL почему нет аналога Event Objects(Win32)
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, PowerUserX, Вы писали:
CS>Наверное потому что такой примитив добавить тривиально можно, как-то так:
CS>
Абсолюьно неправильная реализация :
Во-первых, wait может сработать просто так (фантомные просыпания).
Во-вторых, если один поток сделает notify_one а второй не будет сидеть в этот момент на wait, то событие уйдет в небытие. О нем никто никогда не узнает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Шахтер, Вы писали:
Ш>>CCore замечательно работает и поверх Windows, и поверх Linux.
PD>Ну и что ? Посмотри ссылку, которую я привел, там как раз моделирование ивентов с помощью мютексов. Я же не говорю, что сделать нельзя. Я просто думаю, что в виду того, что ивенты ядром линукса не поддерживаются, авторы STL решили их не включать. Моделируйте сами как хотите.
Это называется упражнение в телепатии.
Как причина -- идиотская. В ядрах и не должно быть реализации всех мыслимых типов синхронизирующих объектов. Должен быть достаточный базис, позволяющий реализовывать их в приложениях.
STL -- это не библиотека поддержки операционной системы. По задумке, это библиотека программирования общего назначения, предназначенная для облегчения рутинных вещей для программиста.
И как таковая она должна содержать в том числе и широкий набор примитивов синхронизации, предоставляя удобный общий интерфейс для их использования и избавляя программиста от необходимости вникать в нюансы операционной системы.
Например, библиотека fstream скрывает детали низкоуровневой работы с файлами. В Windows мы вызываем функции ReadFile/WriteFile для чтения/записи в файл, а в Linux read/write.
Используя стандартную библиотеку, можно абстрагироваться от этого и писать переносимый код.