Re: [boost] Re: On boost.threads

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-11 08:18:13

From: "Scott McCaskill" <scott_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
[...]
> > A common usage of boost::mutex would be making a library thread safe. If
> > such a library is accessed from a single thread (fairly common even in
> > multithreaded programs) using a win32 mutex would impose a significant
> > overhead.
>
> I know there is probably a desire to avoid the number of configuration
> options for the library, but maybe the right thing to do here is to put
> support for critical sections inside #ifdefs (disabled by default).

This is a possible solution, but it has some significant drawbacks. First, I
must be able to choose, even within a single application, whether I want a
win32 CS or a win32 mutex - and I'd want this win32 application to port well
to pthreads without changes. Second, #ifdef's don't usually interact well
with the ODR.

In the ideal case boost.threads would provide me with two mutex types out of
the box that map to CS and mutex on win32 and to the corresponding mutex
types on pthreads. I don't know whether this ideal is achievable, though,
since critical sections are reentrant but the normal pthread_mutex is not,
so the mapping would be somewhat complicated.

This looks like a good opportunity for a generative design:

typedef boost::mutex<fast | recursive>::type mutex_type;

(where the opposite of 'fast' would be 'scalable' and not 'slow' ;-) )

and

typedef boost::mutex<timed>::type timed_mutex_type;

--
Peter Dimov
Multi Media Ltd.