Usage of condition variables

Usage of condition variables

[malc]

Hello,

Recently in the process of discussing one problem i was having subject
temporarily switched to the condition variables:
http://groups.google.com/group/comp.unix.programmer/tree/browse_frm/thread/5394d00781547266/17c8a349edae9d3c?rnum=1_done=%2Fgroup%2Fcomp.unix.programmer%2Fbrowse_frm%2Fthread%2F5394d00781547266%2F17c8a349edae9d3c%3Ftvc%3D1%26q%3Dmalc%26#doc_b586db199a5fd81a

Also according to:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cond_signal.html

<quote>
The pthread_cond_broadcast() or pthread_cond_signal() functions may be
called by a thread whether or not it currently owns the mutex that threads
calling pthread_cond_wait() or pthread_cond_timedwait() have associated
with the condition variable during their waits; however, if predictable
scheduling behavior is required, then that mutex shall be locked by the
thread calling pthread_cond_broadcast() or pthread_cond_signal().
</quote>

However it seems like members of OCaml team strongly prefer unlock
then signal pattern. Given that Xavier Leroy is also the author of
LinuxThreads there might be some good arguments to have it that way,
or maybe it's because of vmthreads, perhaps someone could give the
rationale?

So far only this:
http://groups.google.com/group/comp.unix.programmer/msg/02751100d1b953e3
was in favour of unlock then signal.

--
mailto:malc@pulsesoft.com

Re: [Caml-list] Usage of condition variables

[skaller]

On Thu, 2006-08-17 at 08:05 +0400, malc wrote:

> <quote>
> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
> called by a thread whether or not it currently owns the mutex that threads
> calling pthread_cond_wait() or pthread_cond_timedwait() have associated
> with the condition variable during their waits; however, if predictable
> scheduling behavior is required, then that mutex shall be locked by the
> thread calling pthread_cond_broadcast() or pthread_cond_signal().
> </quote>
> 
> However it seems like members of OCaml team strongly prefer unlock
> then signal pattern.

When something is predictable, there is often a loss of efficiency
compared to a more indeterminate option.

In this case I'd guess that mutex lock/unlock triggers
a scheduling operation because synchronisation is required
anyhow. If there are multiple signallers it may be more
efficient to delay long enough for the signals to be
collated, and fire off the condition check only once.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Usage of condition variables

[Xavier Leroy]

> [Use of condition variables]
> However it seems like members of OCaml team strongly prefer unlock
> then signal pattern. Given that Xavier Leroy is also the author of
> LinuxThreads there might be some good arguments to have it that way,
> or maybe it's because of vmthreads, perhaps someone could give the
> rationale?

That's an old debate -- I've seen threads of 100+ messages on this
topic back in the days when I read comp.programming.threads.

My take on this is that both patterns are correct if your program is
reasonable, i.e. no real-time scheduling with priorities, and all uses
of Condition.wait are protected against spurious wakeups (as they
should always be).

Moreover, the "unlock then signal" variant is slightly more efficient
with naive thread implementations such as LinuxThreads, because
"signal then unlock" can cause threads waiting on the condition to be
restarted only to block immediately on the mutex.  (More sophisticated
implementations can avoid this by clever manipulations of wait queues.)

Butenhof's book on POSIX threads probably contains a better discussion
of the issue.

- Xavier Leroy