[Patch/RFC] tr1::shared_ptr<> removal of lock, choosing thread safety

[Peter Dimov]

Phillip Jordan wrote:

> 2) The test case. Right now, it just tries to provoke potential race
> conditions by running the code in questions as possible in each
> thread.
> This is obviously a stochastic approach an may give false positives.
> I'm
> not aware of any other useful tests to perform to check for thread
> safety, other than maybe formal verification, which doesn't seem to be
> anywhere near mature enough. Tips from the gurus would be appreciated,
> as I need similar, but more complex test cases for the lock-free
> containers.

In addition to your test, you might consider something along the lines of

http://www.boost.org/libs/smart_ptr/test/weak_ptr_mt_test.cpp

It's still a probabilistic approach, but with a slightly better coverage of 
the possible races.

> - Specific to the shared_ptr, I'll probably put back the lock for the
> shared_ptr<T, false> specialisation when __GTHREADS is defined, in
> case
> any existing code relies on it being there. (despite the standard or
> documentation not saying anything about thread safety)

The standard doesn't say anything about thread safety because in its present 
form it has no notion of multiple threads, but tr1::shared_ptr is intended 
to be thread safe. If the next standard is made thread-aware - and this is 
very likely to happen - tr1::shared_ptr will be described as offering the 
same level of thread safety as most C++ types (multiple reads to the same 
instance OK, multiple writes to distinct instances OK.)