| Код |
|
LockEvents:
| Код |
|
структура Events такова:
Events[ evidLock ] - семафор
Events[ evidAbort ] - событие останова
Events[ evidWake ] - холостой ход
Events[ ... ] - динамические события
далее, есть статический набор воркеров(потоков), которые реагируют на динамические события,
воркеры могут менять содержимое Events, следовательно так же блокируют работу с этим вектором с помощью Lock/UnlockEvents,
но, чтобы не было дедлока, перед этим необходимо активировать событие evidWake, которое пробуждает поток x и выводит его из эксклюзивного участка кода
для таких случаев предусмотрен метод http://msdn.microsoft.com/en-us/library/windows/desktop/ms686293(v=vs.85).aspx,
который должен атомарно активировать одно и перейти в режим ожидания второго объекта ожидания,
т.е. работа воркера, с учетом LockEvents должна быть такой:
| Код |
|
все работает хорошо, если не считать редких случаев, когда наступает дедлок,
путем анализа сообщений диагностики, обнаружил его именно на вызове SignalObjectAndWait,
т.е. вызов SignalObjectAndWait активирует evidWakeup но перед ожиданием evidLock, видимо, все же успевает переключить контекст на поток x, который спокойно отрабатывает холостую итерацию и проходит критическую точку LockEvents(), что и вводит воркер в ступор
решил проблему на воркере, путем периодического вызова SignalObjectAndWait, по истечении 200мс,
но основной месаж все же остался: SignalObjectAndWait таки уже не атомарен,
и альтернативы, по всей видимости нет, или я что-то упустил?
тем не менее, в 2008-м MSDN, он еще atomically:https://docs.google.com/open?id=0B3exyGGpaHAeNjM4NGIwM2YtOTM5Ni00YmQ2LTk5YmEtOWY5NjRmYmY2NDcy
p.s.: похоже, пора обновлять документацию
