Re: Thread Checking the Queue data in an infinite loop

What's wrong with just fully draining a queue after an event was signalled?
I don't see any advantage of a semaphore. For a semaphore you'll have one
mandatory WFSO per a queued item, and for an event in high load condition
you'll have several items per WFSO, which reduces overhead somewhat.

You have to protect the queue in any case. You can use a lock-free
single-linked list, though, grab it completely and then process at your
leisure, without need of any synchronization.

You don't have to receive an event and grab a mutex in an atomic operation.

Yes, spurios wakeups are then possible, and it's trivial to handle.

"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message
news:d6qfo35ic9lfg6qvd67mmdmh122aorslql@xxxxxxxxxx
I disagree with Joe (above), and think that your proposal (using an event
to
signal a thread that's WaitForSingleObject on the event) is just fine.

Two problems with using an auto-reset event:

1. The reader would have to drain the queue each time it gets control. To
see why, imagine the writers adding N elements before the reader is ever
signaled and never adding any more.

2. The reader also has to prevent the writers from adding to the queue
while it is draining it, which means grabbing the mutex, but it can't
atomically receive the event notification and grab the mutex. This could
cause spurious future wake-ups for the reader, which would have to account
for this possibility by checking if the queue is empty.

--
Doug Harrison
Visual C++ MVP


.

Relevant Pages

  • Re: RCU+SMR
    ... The single reader just grabbed the entire queue using compare and swap, reversed order making it FIFO and worked off of that util it was empty and then repeated the whole process by grabbing the shared LIFO stack again. ... If you had spare hardware threads, you could have one doing the reverse linking in parallel with the reader thread and improve latency for the reader thread. ...
    (comp.programming.threads)
  • Re: Thread Checking the Queue data in an infinite loop
    ... Yes Reader will acquire the mutex to access the each data element. ... Your pseudo code of Reader and writer has one problem where the reader ... acquires the Lock to drain the whole queue (i have a mutex which has ... all writer threads write to the IOCP and all consumer threads read from the IOCP. ...
    (microsoft.public.vc.mfc)
  • Re: Circular buffer
    ... >If the writer is consistently faster than the reader, ... > its speed with the reader. ... > single element buffer instead of a queue. ...
    (comp.programming)
  • Re: Circular buffer
    ... >If the writer is consistently faster than the reader, ... > its speed with the reader. ... > single element buffer instead of a queue. ...
    (comp.programming)
  • Re: Thread Checking the Queue data in an infinite loop
    ... Yes Reader will acquire the mutex to access the each data element. ... Your pseudo code of Reader and writer has one problem where the reader ... acquires the Lock to drain the whole queue (i have a mutex which has ...
    (microsoft.public.vc.mfc)