From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-28 13:26:04
Howard Hinnant wrote:
> The "mixed thread safe" semantics I find interesting and a little
> worrisome. Having some functionality thread safe and some not could
> be seen as confusing.
"Mixed thread safe" is the way of the future. :-) Really. One needn't be
confused by it. For starters, it's the default thread safety level for all
standard types unless specified otherwise.
Having some non-const methods be thread safe is also not that uncommon. A
lock-free queue for example might offer thread safety for push and pop, but
not for operator=. Only atomic types have a thread safe operator=, and
atomicity for UDTs comes at a cost that is rarely justified.
To get back to std::thread, the reason we want some of its operations to be
thread safe is because we have a specific use case where the usual "the user
needs to use a mutex" doesn't work.
In particular, we want, given a std::thread X, thread A (or threads A1...An)
to be able to join it and thread B to be able to cancel it, unblocking A.
This can't be achieved by a simple user-level mutex protection because it
will deadlock. Thread A will lock the mutex protecting X, join and block
with the mutex locked. Thread B will attempt to acquire the mutex in order
to invoke cancel and also block. Unless the target thread exits by itself, A
and B will wait forever.
Given that, we also want to not penalize the non-shared case by introducing
more synchronization than needed. The semantics I outlined take care of
both. If we make cancel() const, we can now state that shared_ptr<const
thread> is a safe and useful solution for the sharing use case.
I've no opinion on detach at the moment.