Re: [Boost-users] shared_ptr and thread safety 2

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-06 22:38:12

on Mon Aug 06 2007, gast128 <gast128-AT-hotmail.com> wrote:

> Ovanes Markarian <om_boost <at> keywallet.com> writes:
>
>> 
>> Ok, just looking at the example will bring more light into your questions.
>> 
>> First non-safe scenario:
>> // thread A
>> p = p3; // reads p3, writes p
>> 
>> // thread B
>> p3.reset(); // writes p3; undefined, simultaneous read/write
>> 
>> Either thread B is executed before thread A, then you assign empty
>> shared pointer in thread A (to prior pointer deletion in thread B)
>> OR thread A is executed before thread B, then a valid pointer is
>> assigned in B. Possible scenario here as well: Value of p3 is read,
>> scheduler switches to thread B; deletes pointer owned by p3;
>> switches back to thread A and assignes invalid pointer value to p
>> (deletion of pointee can happen probably twice and it is also
>> undefined what is in memory at the point of assignment and what
>> will be written later on...)  ...  Ovanes Markarian
>
> This should mean that shared_ptr is not at all thread safe, as in above race 
> condition. 

No, it's exactly "as threadsafe as int."  Believe it or not, it's
possible for things to be even less threadsafe when shared data
(e.g. a reference count) is involved.  For example, with p1 and p2
both shared_ptr<T>, 

        pre-thread:

          p1 = p2

        thread A:
        
          p1.reset()

        thread B:

          p2.reset()

is safe.  That sequence would not be safe with a naive
reference-counted pointer that was totally unaware of thread safety.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com