[boost] Re: Boost.Threads: Do we need all those mutexes?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-15 09:19:30

So, would anyone care to summarize their take on what conclusions have 
been reached? I'm afraid I haven't had time in the last few days to 
respond much, or even to analyze everything as much as I would have 
liked; and in many cases, it's not obvious what conclusions were 
reached, if any. As far as I remember, the following topics have come 
up; undoubtedly I've missed something, so please add it to the list.

Lock unification
----------------
Should the three lock types (lock, try lock, timed lock) be combined 
into one?

Conclusion: the lock class should be implemented as a single class 
templated on the mutex type; trying to use operations that the mutex 
doesn't support results in a compile error.

Question: does this mean unification of the lock concepts, too?

Extended lock interface
-----------------------
The lock interface should be extended to make it possible to determine 
if it is locking a particular mutex. How?

Suggestions:
    Mutex& mutex()
    Mutex* mutex()
    void* mutex()
    mutex_id_type mutex()

Conclusion: ???

Mutex/lock interface specification
----------------------------------
The private mutex interface used by locks should be specified so that 
others can write custom mutex classes that work with the Boost.Threads 
lock class.

Mutex unification
-----------------
Should the three mutex types (mutex, try mutex, timed mutex) be combined 
into one?

Conclusion: I think it was concluded that a separate timed mutex is 
necessary. Possibly that the mutex and try mutex should be combined. 
That this combined mutex should optionally provide timed operations if 
they can be supported efficiently by the underlying platform.

Read/Write lock demotion
------------------------
What should the lock demotion syntax look like?

Conclusion: ???

Read/Write lock promotion
-------------------------
Should lock promotion be supported or is it too problematic? Should 
there be failable promotion, promotion that uses upgradeable locks and 
doesn't fail, or both? What should the promotion syntax look like?

Conclusion: ???

Other miscellaneous topics
--------------------------
* The Boost.Threads implementation of a condition variable waiting on a 
recursive mutex that is locked more than once is buggy.

* The very idea of a condition variable waiting on a recursive mutex 
that is locked more than once is a bad idea.

Topics that were postponed
--------------------------
* Making locks movable

* Supporting "if (Lock l = ...)" syntax

* Dealing with how time is specified in timed lock operations.

Mike