Boost logo

Boost :

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2000-08-08 17:30:09


--- William Kempf <sirwillard_at_[hidden]> 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).

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

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


Do You Yahoo!?
Kick off your party with Yahoo! Invites.

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