Re: async queue?

[Mark Mielke <mark mark mielke cc>]

On Thu, Dec 13, 2001 at 04:25:53PM +0100, Sebastian Wilhelmi wrote:
> > > > 2) The Async Queue code should actually use two conditionials instead
> > > >    of one after implementing the above code. One conditional is used
> > > >    to wake up threads that are waiting to pop, while the other conditional
> > > >    is used to wake up threads that are waiting to push.
> > > I think, one cond var still suffices, as at a given time only one side
> > > (either consumer or producer) can be waiting.
> > If more than one producer or consumer is waiting, threads on that side
> > of the queue will always be woken up only to fall asleep again.
> If you mean, that upon arrival of a new item all waiting threads are
> woken, you are wrong. With g_cond_signal only one will be woken.

For the situation I was presenting, I was speaking about 2) being
required after 1) was implemented. For this situation, it isn't the
possibility of all threads being woken up, as much as is it the wrong
thread being woken up. There are two conditions. The first condition
is "something changed that may allow you to add to the queue." The
second condition is "something changed that may allow you to remove
from the queue."

If they are represented using a single conditional, the condition
becomes "something changed to the queue that may affect you."

The "you" would be a single thread. Specifically, it is whatever
thread the threading implementation schedules to execute next.

If the max size is sufficiently large, the chance of both push() and
pop() threads blocking at the same time is remote. As it is remote, it
doesn't matter too much if a thread wakes up unnecessarily. The case I
remain concerned about is a thread waking up, only to go to sleep.
Notification of the condition destined to the 'next' thread may miss
the 'appropriate' thread, causing the 'appropriate' thread to remain
blocked.

If you can prove to me that this doesn't happen, I'll be happy to
retract 2) as a requirement.

> > As an example of this, I believe that several GThread objects in a
> > GThreadPool will waiting on the same conditional. (i.e. multiple
> > consumers) If several threads were issuing work items to the
> > GThreadPool, we have several producers as well.
> Yes, but at a given time there can either be waiting threads _or_ queued
> data for threads, not both at the same time (of course, if you lock an
> async queue, there can be both waiting threads and waiting data, but
> that unfolds quite happily, once you unlock the queue again).

Here's another thing to think about: Does g_cond_signal() need to be
called for every single push()? g_cond_wait() is not called for every
single pop()... If the item being pushed causes the length to be less
than or equal to the number of waiting threads, g_cond_signal() needs
to be called. The number of waiting threads is currently maintained.

mark

-- 
mark mielke cc/markm ncf ca/markm nortelnetworks com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/