Re: Threads: the Mutex class

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-08 17:38:59

--- In boost_at_[hidden], Dietmar Kuehl <dietmar_kuehl_at_y...> wrote:
> Hi,
> 
> --- William Kempf <sirwillard_at_m...> wrote:
> > Here's a rough starting point for a mutex class.
> 
> I would rather list requirements on mutex classes, leaving as much 
as
> possible in the realm of "implementation detail". This is because I
> expect various flavours of mutex classes and library components 
which
> don't care about which specific one is choosen. How the library
> components are configured to use a certain mutex class is something 
to
> be discussed (two candidates I can think of are templates in some 
form,
> not necessarily a template argument to the component, tough, and a
> global configuration, eg. a macro or a required namespace 
assignment).

I've only given an interface as a means of visualization.  Many 
people won't comprehend what we're talking about here with out it.  
The requirements are pretty much detailed (sketchily) in the 
interface and comments.

> > 	// Creates a new mutex.  If a name is specified the mutex
> > 	// will be created in such a way that it's sharable between
> > 	// processes. Should the sharable functionality be included?
> > 	// Today this would require support from the platform, and
> > 	// if the language were to adopt it it could be complicated
> > 	// to include this on all platforms.  However, the platforms
> > 	// I'm familiar with would allow for this and it's almost an
> > 	// essential quality for some constructs.
> > 	mutex(char* name=0);
> 
> The above approach would cover this one: A mutex for interprocess
> locking might be reasonable but I don't think that it is one of the
> essentials for multi threading.

For multi-threading, no.  For concurrent programming, yes.  Most of 
the issues that exist for threading exist for concurrent programming 
in general and should be addressed, IMHO.

> This has, however, nothing to do with
> POSIX support: I'm pretty sure that a cross process lock can be 
created
> using POSIX mechanisms, although it is not part of the threading
> library (POSIX.4 definitely support semaphores which might be used 
for
> this; however, I haven't looked into the details yet).

pthreads certainly address this issue at least to some extent.  The 
pthread_mutex_attr_t includes an attribute for process shareable.  
The actual sharing requires other POSIX mechanisms (shared memory), 
but it would not be possible with out support from the pthreads 
library.

This particular issue is very debatable. I included it because of 
this reason.

> As a basic
> building block I would like a minimal mutex which does nothing else
> than locking: No interprocess stuff, no recursion. Maybe this would
> already support non-blocking lock attempts.

I'm not sure on the recursion angle.  A non-recursive mutex is very 
prone to deadlock, especially when used within a class's 
implementation.  There's nothing really wrong with supplying two 
types of mutexes for this reason, since the non-recursive type is 
(slightly) more efficient, but the dangers lead me to think we 
shouldn't take this approach lightly.

Non-blocking lock attempts are IMHO an absolute requirement.  I can 
see no reason to have a mutex with out this capability since it 
shouldn't add to the efficiency to leave it out, while a very large 
number of constructs require the ability to do a try_lock.

> > I put most of the things I see as questionable or issues into the 
> > comments above.  Simple useage:
> > 
> > mutex mx;
> > mutex::lock lock(mx);
> 
> Looks good to me.

It's simple and elegant while mostly safe.  There are still some open 
dangers here, but I think any attempt to close them will just make 
the interface unusable.
 
> > The lock class would allow code like the following:
> > 
> > mutex::lock(mx);
> > 
> > which would compile but not behave as some might expect.  I don't 
> > think this is a large issue, but I felt it should be pointed out.
> 
> I think there was a discussion on a similar topic on the Boost list 
but
> I can't remember the outcome...

Someone will, I'm sure.

William Kempf