Boost logo

Boost :

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
> possible in the realm of "implementation detail". This is because I
> expect various flavours of mutex classes and library components
> don't care about which specific one is choosen. How the library
> components are configured to use a certain mutex class is something
> be discussed (two candidates I can think of are templates in some
> not necessarily a template argument to the component, tough, and a
> global configuration, eg. a macro or a required namespace

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
> using POSIX mechanisms, although it is not part of the threading
> library (POSIX.4 definitely support semaphores which might be used
> 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

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
> I can't remember the outcome...

Someone will, I'm sure.

William Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at