Re: Thread Checking the Queue data in an infinite loop

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

See below...
On Sun, 13 Jan 2008 23:11:26 -0800 (PST), prams <pramodjoisb@xxxxxxxxx> wrote:

Hello All,

Mr. Doug Harrison :
Than you for responding

"Remember also that the reader has to acquire the mutex."
Yes Reader will acquire the mutex to access the each data element.
The Prodcucer-Consumer Link suggests the use of two semaphores. I
will have a Bounded buffer which
has a Limit which is Large enough. So what do you suggest about
these use of semaphores. Would it be
Ideal. I will experiment with Pipes solution, Semaphores solution
and let me see.
Since threads are in the same process, I need not put the full data
into the Pipes..Only a Pointer value
would suffice. I am not knowing much about pipes. My statement may be
foolish.

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
to be acquired by reader for accessing one element from the queue and
writers for adding one element to the queue) and writer will have to
wait till the reader releases it and vice versa.
Also while retrieving from the queue the reader is retrieving one
element at a time. I can replace this logic by code which makes a
complete copy to another queue. Then your solution may work fine.

Mr. Joseph M NewComer:
Thank you for responding.
"you can't do SQMS with an approach that "drains" the queue with just
one thread "
I think you meant to say that the Reader thread is slow and writer
threads may be faster and a single Reader thread may not suffice. We
are thinking of introducing another Reader thread which reads a
seperate queue, because there are two seperate Devices from which we
are retrieving data from using seperate threads( writer threads) , we
can have seperate queues. So It would be like two writer threads
writing to corresponding queues. Two reader threads reading the
corresponding queues and retrieving data.
****
So how does the writer know which queue to write to? That's what an IOCP handles nicely;
all writer threads write to the IOCP and all consumer threads read from the IOCP. The
notion that a reader will drain the queue and this will be a problem suggests that the
architecture in which this is a problem is the wrong architecture! Multiple writers
writing to a single queue and multiple readers reading from that queue, one element at a
time, avoids this problem.

I think you have taken a simple problem and made it needlessly complex by trying to create
strange and wondrous synchronization. "The best synchronization is no synchronization"
(see my essay of that title). Yes, an IOCP uses synchronization deep inside to handle
concurrent readers and writers, but the key idea is that YOU DON'T HAVE TO WORRY ABOUT HOW
IT WORKS! It just works, and always does the right thing. You don't need to make a
simple problem hard.
****
Sir, your gut feeling and confidence on I/O Completion Ports makes me
feel that I should try with it once. I will write an example program
and test it.
****
You can code up an IOCP interthread handler in about five minutes and it works the first
time. Note that the very first time, you will spend a bit longer reading the docs, so the
very first time might take more like 15 minutes.

Writer thread:

Thing * data = new Thing(...args here...);
PostQueuedCompletionstatus(iocp, 0, DATA_ITEM, (LPOVERLAPPED)data);

Reader thread:

BOOL running = TRUE;
while(running)
{ /* read loop */
LPDWORD unused;
ULONG_PTR key;
Thing * data;
GetQueuedCompletionStatus(iocp, &unused, &key, (LPOVERLAPPED *)&data, INFINITE);
switch(key)
{ /* key */
case SHUTDOWN_ITEM:
running = FALSE;
continue;
case DATA_ITEM:
...deal with data
delete data;
} /* key */
} /* read loop */

This is the basic schema, you can add error checking, more kinds of events, etc. as you
need. You can instantiate as many reader threads and as many writer threads as you want.

To shut the threads down

for(int i = 0; i < num_threads; i++)
PostQueuedCompletionStatus(iocp, 0, SHUTDOWN_ITEM, NULL);

that's it.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

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: 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)
  • RE: single-reader/ multiple-writers message queuing
    ... The OS message queues support multiple writes and a single reader. ... - The reader creates the message queue. ... you can have writer threads block until ...
    (microsoft.public.windowsce.app.development)