On Wed, 2011-03-09 at 10:54 +0000, Steven van der Vegt wrote:
> > From what I see, you have made two changes:
>
> > 1. you have moved the NULL check from the caller in http.c to the getter
> > in pound.c (a NULL check is required in any case, as the condition
> > wake-up may occur even when there is no data to be consumed)
>
> This is true, but why place this responsibility by the caller? This
> get_thr_arg is meant to be partial right? Now it is not. Also I think the
> code is more clear now, but that's of course a matter of taste :)
As you say, a matter of style and taste.
> > 2. you have replaced the cond_signal with a cond_broadcast in the
> > enqueing function
>
> > The first change should make no difference (it is just moving the actual
> > check to another place). The second will cause more threads to wake-up,
> > quite often more than are required. I must admit am not at all clear how
> > should this help.
>
> This will prevent lost-wakeups. So instead of waking-up one thread, You wake
> them all up.
>
> I also made an error in my code. After every dequeue() I signaled This is not
> necessary. I attached my new pound.c file.
No error. Signals are lost if no thread is waiting. If you don't signal
you may well end up with things on the queue and all threads sleeping.
For example:
- assume 8 worker threads
- you get 12 requests in quick succession
- the first 8 are consumed by the threads
- the following 4 are enqueued while the threads are busy
- the 8 threads finish working and go to sleep, waiting for a signal
- 4 requests stay in the queue
This is the reason that the broadcast does not help (the signal is
ignored by active threads) and the signal is necessary on dequeue.
--
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-32-512 30 19
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
