аналог waitformultipleobjects в linux
Модератор: Модераторы
а "объекты" какие нужно ожидать? (из pthread-ов, файлы, сокеты, процессы?)
-
ElectroGuard
- новенький
- Сообщения: 71
- Зарегистрирован: 03.06.2016 11:10:22
Массив синхронизационных Event'ов. Необходимо их все ожидать.
ElectroGuard писал(а):Массив синхронизационных Event'ов. Необходимо их все ожидать.
я так думаю, что придётся писать чуть больше, чем написано в RTLEvent-ах.
глядя на текущую реализацию FPC RTLEvent-а, видно, что он сделан через pthread mutex и pmutex condition.
SetEvent() посылает pthread_cond_signal() на один cond, связанный с этим евентом.
Очевидно, что реализацию необходимо расширить до списка cond.
Т.е.
WaitForMulitpleObjects() (с поправкой на то, что в него будут переданы только event-ы)
должен создать ещё один cond и добавить его в очередь к каждому event-у, которые ожидаются.
Соответственно, любой из ожидающий евентов, может дать сигнал этму cond.
После чего WaitForMultipleObjects - должна выяснить, какой из евентов просигналил (ну чтобы был разумный результат)
и убрать дополнительные cond-ы с очередей всех других евентов.
Вот и всё. Эффективность максимальная. Циклов проверки состояния нет.
---
Если я не ошибаюсь, то эту систему можно прикрутить к RTL в runtime-е, написав свой вариант cthreads-ов.
скалогрыз писал(а):Соответственно, любой из ожидающий евентов, может дать сигнал этму cond.
После чего WaitForMultipleObjects - должна выяснить, какой из евентов просигналил (ну чтобы был разумный результат)
и убрать дополнительные cond-ы с очередей всех других евентов.
Вот и всё. Эффективность максимальная. Циклов проверки состояния нет.
Согласен, красивое решение. При необходимости так и сделаю у себя.
Добавлено спустя 6 часов 22 минуты 58 секунд:
скалогрыз писал(а):Вот и всё. Эффективность максимальная. Циклов проверки состояния нет.
Покрутил код и получается так, что таким образом (без опросов) можно ловить ивенты, выставленные ручным способом (своим кодом).
Если нужно ждать событие от ОС (окончание операции ввода/вывода), то придется все равно периодически опрашивать циклом. Увы.
wadman писал(а):Если нужно ждать событие от ОС (окончание операции ввода/вывода), то придется все равно периодически опрашивать циклом. Увы.
операции ввода/вывода не совпадают с тех заданием:
ElectroGuard писал(а):Массив синхронизационных Event'ов. Необходимо их все ожидать.
WaitForMultipleObjects - это же очень хитрая операция, завязанная на особенностях реализации ядра Windows.
Хитрость в том, что "объекты" могут быть разношорстными по своей природе.
По-этому очень важно оговаривать какие "объекты" нужно ожидать. (Т.к. если нужна подзадача, то возможно она уже решена, cм пост Sergei I. Gorelkin про poll и select)
В тех случаях когда нужно решать задачу, в которой придёться ожидать некий салат из объектов (ожидать нужно и евенты и файлы, и ещё что-нибудь),
тогда придёться создавать дополнительные объекты синхронизации.
Какой-нить pipe.
Сначала будет инициолизирован дополнительный cond, и добавлен для каждого евернта.
Потом нужно собрать все файл дескрипторы, которые нужно ожидать + дополнительный pipe.
Все эти дескрипторы будут ожидаться через poll()
В том случае, если ивенту дан сигнал, то кроме прочего, этот ивент должен будет записать что-нить через pipe.
Именно эта запись через pipe - "разморозит" ожидающий события poll()
а индикация того, что разморозился именно дополнительный pipe - даст знать, что событие произошло в ивентах.
дополнительная писанина, конечно, и расход файловых дескрипторов, зато будет работать.
скалогрыз писал(а):операции ввода/вывода не совпадают с тех заданием:
В общем-то для себя реализовал.
с ИО операциями не стал пока прикручивать...Для синхронизации своих потоков отлично подходит. За идею спасибо.