From: Andy Glew (glew_at_[hidden])
Date: 1999-12-30 21:53:57
Ah, to hell with it!
Template argument creep is ugly, ugly, ugly....
(it's a pity that we don't have keyword arguments....)
Boost should just define a shared_ptr API
that makes no multithreading guarantees.
The reference implementation should not be MT safe,
neither mutexed nor even read/write atomic.
Boost might consider a "standard" API for minimal
multithread operations - lock acquisition and release -
as somebody posted an example.
Using this, Boost might consider a mutexed_ptr<T>
wrapper, and perhaps mutexed wrappers for a number
of other data structures, such as STL containers.
Implementors should be encouraged to provide different
flavours of shared_ptr, if they feel aggressive, including
mutexed, and, if they are very, very, skillful, read/write
atomic but not mutexed versions. Selected by conditional
compilation, include path games, or whatever...
The latter allows shared_ptr to be more of a drop-in
replacement for a scalar pointer, but this is a losing battle:
C++ smart pointers aren't pointers. Lack of low-cost write
atomicity is just yet another difference between smart pointers
and ordinary pointers.
If different shared_pointer implementations are encouraged.
it might be useful to include multithreading support as a
query operation - a property of type traits. Is it already there?
Queries to indicate whether an implementation is
a) totally multithread safe - the semantic equivalent of mutxed
b) single entry, i.e. mutexed (a performance query)
c) multiple simultaneous readers / single writer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk