Boost logo

Boost :

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-17 11:07:15


On Sat, 17 Jul 2004 11:42:18 -0400, Michael Glassford
<glassfordm_at_[hidden]> wrote:
> Matt Hurd wrote:
[snip]
> Actually, all I meant is that I liked the idea of a null mutex (in the
> context of it being substituted for a real mutex in a single-threaded
> application).
>
Kewl. I think that will be a nice small implementation and large
conceptual step forward.

Another big step forward might be being able to write to a shareable
mutex style (rw) and have it work with (by being substitutable for)
the other mutex types, policy or not (hopefully with policies). This
will make one code base suitable for null_mutex ... shareable_mutex
(rw) if you write to the shareable (rw) case.

I think we are already largely headed down that line. The main trick
here is making shared / exclusive access (r/w) at the lock interface
map to just exclusive for the exclusive only mutexes. The other facet
is accepting and ignoring the shared / exclusive priorities, e.g.
interleaved, exclusive_priority (write priority), etc on mutex
construction for the base mutex types. This is a necessarily
different approach to having compile time errors for features that are
not appropriate. Compile time errors are still appropriate other
features, such as timed locks which may not be available due to
config/policy.

I do have this dream of the types being able to minimally configure
themselves based on their use which would be appropriate for some
design choices... think of it as a reverse policy approach, but that
is research not dev... AFAIK

Regards,

Matt Hurd.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk