Boost logo

Boost :

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?

    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.


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