Subj : Re: Lock Free Programming with Boost::shared_ptr instead of Hazard  Pointers
To   : (Usenet)
From : Chris Thomasson
Date : Wed Mar 23 2005 07:02 pm

Sorry for the last post, it only posted to c.p.t. ignore it.
damn outlook! ;)


> Joe Seigh wrote:
>> Roshan Naik wrote:
>>>2) Shared_ptr is not thread safe ?? I dont know. But it is possible that
>>>    it is currently not implemented to perform its operations in an
>>>atomic/thread-safe fashion. But perhaps that can be fixed (with help
>>>from the future standard..volatile/CAS). But ofcourse, hazard pointers
>>>technique also relies on the similar requirements from the standard.
>> I believe there's a parameter to make it mostly threadsafe.  The non
>> thread-safe part is you have to know the refcount of any shared_ptr's
>> you copy won't go to zero during the copy operation.  Basically, you
>> have to "own" the shared_ptr you're copying.
> Which basically conforms to the "an object can't protect against it's
> own destruction" mantra. Doesn't that also hold true for the atomic_ptr?
> (Haven't checked yet, so really don't know).


I believe he is talking about the "classic" race-condition inherit with all
"basic" reference counting schemes. Here is a description of the data-race:

http://groups-beta.google.com/group/comp.lang.c++.moderated/msg/b8c1e7bd6b54f541

Joes algorithm overcomes this nasty and subtle condition. It allows for
"strong" thread-safety via. real atomic pointer.




p.s.

I am leaving the SenderX alias behind. It looks like lock-free is slowly
being taken out of the "X-Files Status"...

;)


-- 
http://appcore.home.comcast.net/
(portable lock-free data-structures)



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

.