Re: async queue?

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Mark,

> > 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.

I agree, that it isn't as obvious, as I first thought. We might indeed
be better of with just two cond vars, they are typically not very
costly. But I'll have a look again, once the implementation is written.
If it is easily seen, that one cond var suffices, we'll use one, if the
situation you describe can happen, two have to be used (They can be
allocated lazily to make the impact even smaller)

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi