Escaping the Tyranny of the GC: std.rcstring, first blood

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/14, 10:22 PM, Rainer Schuetze wrote:
>
>
> On 15.09.2014 21:49, Andrei Alexandrescu wrote:
>> On 9/15/14, 12:43 PM, po wrote:
>>>
>>>> As I understand the issue it works if you make sure to transfer
>>>> ownership explicitly before the other thread gains access?
>>>>
>>>> Maybe this is more clear:
>>>>
>>>> http://www.1024cores.net/home/lock-free-algorithms/object-life-time-management/differential-reference-counting
>>>>
>>>>
>>>>
>>>
>>>   Ah, I think I follow.
>>>
>>> So in C++ terms:
>>>   It basically requires either a global shared_ptr, or that you passed
>>> one around by reference between threads. And that you then killed it in
>>> one thread at the exact moment the control block was read in another
>>> thread. That blog post discusses a solution, I wonder if that is
>>> implemented in C++'s shared_ptr?
>>
>> No, and it neeedn't. The article is not that good. In C++, if a thread
>> must increment a reference counter while it's going to zero due to
>> another thread, that's 100% a programming error, not a concurrency
>> error. That's a well known and well studied problem. As an aside,
>> searching the net for differential reference counting yields pretty much
>> only this article.
>
> Huuh? So you must not read a reference to a ref-counted object that
> might get changed in another thread?

I didn't say that.

> Maybe you mean destruction of the
> shared pointer?

I meant: by the time the smart pointer got to the thread, its reference 
count has increased already.

> Please note that the scenario is also described by Richard Jones in his
> 2nd edition of the "Handbook of Garbage Collection" (see algorithm 18.2
> "Eager reference counting with CompareAndSwap is broken").

I agree such a problem may occur in code generated automatically under 
the wraps for high-level languages, but not with shared_ptr (or COM 
objects etc).


Andrei