Subj : Re: pthread_cond_signal() semantics
To   : comp.programming.threads
From : Joseph Seigh
Date : Sun Jan 09 2005 08:32 am

On Sun, 09 Jan 2005 09:00:36 +0100, Giancarlo Niccolai <searchforme@ingoogle.com> wrote:

> Joseph Seigh wrote:
>
>> On Sat, 08 Jan 2005 23:32:01 GMT, William Hoggarth <me@whoggarth.com>
>> wrote:
>>
>>>
>>> Does pthread_cond_signal() just make the signalled thread runnable, with
>>> the guarantee of the mutex lock when it runs?
>>
>> For some implementations.  Others may queue the woken threads onto the
>> mutex wait queue instead.
>
> AFAIK, it is not required; that is the implementations doing it (waking
> waiting threads immediately) are overdoing their jobs. Many here thinks
> that waking threads as mutex are unlocked is not good; I am with them.
>
> IMHO is incorrect to swap the current thread out as soon as it signals or
> unolocks and make an older thread immediately runnable: time slice MUST be
> used as long as possible. Also, this would make absolutely no sense in a
> SMP environment. If you have two or more processors, then what should
> happen when signaling? how much fast the other waiting thread(s) may get
> running in the other processor? Would your signaling thread be swapped?
> Would it make good to your code and performances? I can see some use for
> mutex relase-thread wake, that's true, but I can see that with a little
> more effort any code using waking mutex releases can be at least made more
> efficient without it.
>
> If you want to know that other threads have done their job on incoming data
> before reading and signaling again, you have to create another condition on
> job_done and wait for it in the signaling thread; no other (sensible)
> option.
>
You're confusing adaptive vs. FIFO mutexes and the problem Linux has with
futex_wake.  If you move the signal outside of the critical region then you
effectively get the following on Linux.

   while(1) {
      get_input();

      pthread_mutex_lock(&mutex);
      copy_input_to_buffer();
      pthread_mutex_unlock(&mutex);
      pthread_cond_signal(&cond);
      sched_yield();
   }

There's a little bit of concurrency loss if get_input() was going to block
anyhow.


-- 
Joe Seigh

.