Re: [boost] What's a Mutex ? (Was: Re: Threads)

From: Pavel Cisler (pavel_at_[hidden])
Date: 2000-08-06 04:51:08

Valentin Bonnard wrote:

> scleary_at_[hidden] wrote:
> >
> > > As for those wanting to start with vast definitions...
> > >
> > > I'm not sure why we need to do this.  Most definitions are well known
> > > to anyone who's done concurrent programming.  Unless we're striving
> > > to come up with new jargon there's nothing to define.
> >
> > Everyone knows what a "mutex" is.

Mutexes are usually used as semaphores in a number of threading libraries.
Unfortunately while the behavior of a semaphore is very unambiguously
defined in vast numbers of computer science texts, meanings of mutexes and
their behavior seems to differ quite a bit in different implementations and
contexts.

For instance the popular threading library Pthreads for Linux allows you to
create three kinds of mutexes with different locking semantics.

By using the pthread_mutex_init call you may create a "fast" mutext that
behaves pretty much identically to Dijkstra's semaphore.

The second, default default kind of a mutex in Pthreads is called "error
checking". When using a default mutex kind, it is an error to try to lock a
mutext from a thread that already owns the mutex. Also, it is an error to
unlock the mutex from a thread other than the one that currently owns it.
Both attempts will result with an error returned. This is intended as an
enhancement of the original semaphore behavior, making the concept of the
ownership of the locking primitive stronger and preventing threads from
locking themselves.

Finally, by using the pthread_mutex_init call you can create a third kind of
mutex a "recursive" mutex -- This is arguably the most fancy locking
primitive -- when a thread that already owns the mutex tries to lock it
again, it does not block itself, instead a locking count gets bumped up.
Later to give up the mutex, the thread has to unlock it as many times as it
locked it. This "smarter semaphore" is in behavior pretty much identical to
for instance the BLocker lock class in BeOS which is used as the main
locking primitive in it's heavily threaded C++ application framework.

Clearly the three mutex kinds in Pthreads have very different behavior and
it would be more convenient if they had distinct names -- the "fast" mutex
should be just called semaphore, the name mutex could be reserved for a
locking primitive with the behavior of the Pthreads "error checking" mutext
and some other distinct name (recursive mutex) could be used for the third
kind.

Pavel