winapi - What are alternatives to Win32 PulseEvent() function? -

the documentation win32 api pulseevent() function (kernel32.dll) states function “… unreliable , should not used new applications. instead, use condition variables”. however, condition variables cannot used across process boundaries (named) events can.

i have scenario cross-process, cross-runtime (native , managed code) in single producer has interesting make known zero or more consumers. right now, well-known named event used (and set signaled state) producer using pulseevent function when needs make known. 0 or more consumers wait on event (waitforsingleobject()) , perform action in response. there no need two-way communication in scenario, , producer not need know if event has listeners, nor need know if event acted upon. on other hand, not want consumers ever miss events. in other words, system needs reliable – producer not need know if case or not. scenario can thought of “clock ticker” – i.e., producer provides semi-regular signal 0 or more consumers count. , consumers must have correct count on given period of time. no polling consumers allowed (performance reasons). ticker few milliseconds (20 or so, not regular).

raymen chen (the old new thing) has blog post pointing out “fundamentally flawed” nature of pulseevent() function, not see alternative scenario chen or posted comments.

can please suggest one?

please keep in mind ipc signal must cross process boundries on machine, not threads. , solution needs have high performance in consumers must able act within 10ms of each event.

i think you're going need little more complex hit reliability target.

my understanding of problem have 1 producer , unknown number of consumers of different processes. each consumer can never miss events.

i'd more clarification missing event means.

i) if consumer started run , got before waited on notification method , event occurred should process though wasn't quite ready @ point notification sent? (i.e. when consumer considered active? when starts or when processes first event)

ii) likewise, if consumer processing event , code waits on next notification hasn't yet begun wait (i'm assuming wait -> process -> loop wait code structure) should know event occurred whilst looping around?

i'd assume i) "not really" it's race between process start , being "ready" , ii) "yes"; notifications are, effectively, queued per consumer once consumer present , each consumer gets consume events produced whilst it's active , doesn't skip any.

so, you're after ability send stream of notifications set of consumers consumer guaranteed act on notifications in stream point acts on first point shuts down. i.e. if producer produces following stream of notifications

1 2 3 4 5 6 7 8 9 0

and consumer a) starts , processes 3, should process 4-0

if consumer b) starts , processes 5 shut down after 9 should have processed 5,6,7,8,9

if consumer c) running when notifications began should have processed 1-0

etc.

simply pulsing event wont work. if consumer not actively waiting on event when event pulsed miss event fail if events produced faster can loop around wait on event again.

using semaphore wont work if 1 consumer runs faster consumer such extent can loop around semaphore call before other completes processing , if there's notification within time 1 consumer process event more once , 1 miss one. may release 3 threads (if producer knows there 3 consumers) cant ensure each consumer released once.

a ring buffer of events (tick counts) in shared memory each consumer knowing value of event last processed , consumers alerted via pulsed event should work @ expense of of consumers being out of sync ticks sometimes; if miss 1 catch next time pulsed. long ring buffer big enough consumers can process events before producer loops in buffer should ok.

with example above, if consumer d misses pulse event 4 because wasn't waiting on event @ time , settles wait woken when event 5 produced , since it's last processed counted 3 process 4 , 5 , loop event...

if isn't enough i'd suggest pgm via sockets give reliable multicast; advantage of move consumers off onto different machines...