Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-04 12:26:56

--- In boost_at_[hidden], scleary_at_j... wrote:
> > > Everyone knows what a "mutex" is. However, the problem comes
with the
> > > precise definition of a mutex. Is it recursive (i.e., can a
thread lock
> it
> > > if it already owns it)? Is it statically-initializable (so it
can be
> used
> > > in program startup/shutdown code)? These questions demonstrate
the need
> for
> > > a hard definition even of the simplest of synchronization
> >
> > Are the implications to saying 'Yes' to both these?
> I don't know. The point of my message was that we need to flesh
out all the
> details so we know how we can use it. Are pthread-mutexes
> AFAIK, there is no way to statically-initialize a mutex
> under Win32.

I don't believe that pthread mutexes (muti?) are recursive. I'm also
unaware of any problems specifically with critical sections being
statically initialized under Win32. However, most "mutex"
implementations are C based implementations that require two step
creation that even when wrapped in a C++ object results in a race
condition when attempted to be used in this manner. It would be
possible to work around such limitations in our library, however. At
least to the extent that the language will allow us to... but unless
there's a language change then static initialization is problematic
at best any way, since there's no gaurantee about the order or
concurrency requirements of using static data with multiple threads.

Regardless, I don't see how any of this applies here, since neither
library need be used for the implementation details here. (Not that
I'm saying they shouldn't or won't be...).

> We can use features & generative programming here to define the
> characteristics of the mutex type we want. The problem comes in
> features are not available for some platforms (e.g., static-init &
Win32) --
> what do we do then? My pool<> allocator uses a non-static-init
mutex, and
> just says that there can't be multiple threads running before main
() starts.
> If we had a static-init mutex, multithreading before main() would be
> acceptable. So the semantics of another piece of boost can change
(in a
> subtle way) based on what platform we're running on; there should
at least
> be a warning to note this (BOOST_COMPILE_TIME_WARN, anyone? :).

The mutex, especially, need not rely on any underlying support from
another thread library in it's implementation. If we're to devise a
proper library we may need to ignore the existance of other threading
libraries. Yes, the implications you mention need to be discussed
thoroughly, but that's precisely what I'm trying to get started here.

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