Re: Atomic Reference Counting - Do you think this would be useful to Boost?
Earl Purple wrote:
kanze wrote:
shared_ptr doesn't have the semantics you want when passing
objects accross threads. What you need is auto_ptr.
Regretfully, there's no way of getting an auto_ptr from a
shared_ptr. (On the other hand, I've never had any problem with
auto_ptr's semantics in this case, using raw pointers for
weak_ptr's. Perhaps a weak_ptr for auto_ptr would be the
answer.)
No, auto_ptr doesn't work in STL collections and prodcon_queue
uses std::deque.
So. You take it out of the auto_ptr, and put it into the queue.
During which time, the queue is the owner, and not the auto_ptr.
That's an implementation detail, of course. The important point
is that the interface to the queue uses an auto_ptr, so that the
thread yielding possession cannot continue accessing the object.
Behind the scenes, you do whatever is necessary for it to work.
(My own MessageQueue also uses deque.)
The producer thread is unlikely to want to access the object
once posted to the queue so the only other solution would be
to have the consumer that eventually picks it up make an
explicit call (eg call delete if we're using raw pointers).
With a well designed system, the producer thread cannot access
the object once posted to the queue. I don't want the
robustness of my software to depend only on good intentions.
Of course this explicit call could be wrapped in a specific
smart-pointer.
As far as I'm aware with boost shared_ptr, if you want to use
thread-safety you have to use it all the time, there's no way
to choose.
As far as I'm aware of with boost shared_ptr, once the object
belongs to a shared_ptr, it always belongs to shared_ptr;
there's no way around that. And that model doesn't work accross
thread boundaries, since shared_ptr doesn't have the desired
semantics for the boundary.
My guess is that tr1 doesn't have any thread-safety feature at
all because it's not standard and tr1 has to be standard.
TR1 isn't part of the standard yet. It is in the process of
being adopted. As are threads. Presumably, the version of the
standard which adoptes TR1 will also address thread safety
issues. But I don't think anyone has yet given consideration to
this with regards to shared_ptr.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]