Subj : Re: pthread_cond_signal() semantics
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sun Jan 09 2005 06:47 pm

Joseph Seigh wrote:

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

I did not mention FIFO nor adaptive mutexes. I either did not talked about
linux (mis)-behavior or other specific OS's. I just state that the program
should be built so that not to rely on specific behavior of the scheduler
in case of condition signaling or mutex unlocking. I cannot see any
portable and threadsafe program relying on other threads stepping in and
perform their job at mutex release or condition signaling. If the above
loop works is just because the above code does not rely on workers to
perform their job after the buffer is updated (which is OK, if the program
is built to work this way). I didn't talk about efficiency either.

So, IMHO my previous mail has nothing to do with the above statement.

Gian.

.