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
