shared_ptr questions
I'm looking at shared_ptr and weak_ptr as a TR1 standard approach. It is hard to follow the implementation, but I'm wondering about some specific issues. My set of classes (http://www.dlugosz.com/Repertoire/refman/Classics/Smart%20Pointers%20Overvie...), published over ten years ago, has similar features. My class "baro" is like your weak_pointer. I recall a threading issue where one thread is dropping the last owned reference at the same time another thread is realizing a weak_pointer. The first decrements the refcount to zero, and the second increments it again. Is the object destructed? I'm using a specific mechanism to support this and related features, and I don't see that in your code. Is the Boost implementation for Windows (32 and 64-bit) robust and lock-free in cases like this? How does it work? --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
John Dlugosz wrote:
I'm looking at shared_ptr and weak_ptr as a TR1 standard approach. It is hard to follow the implementation, but I'm wondering about some specific issues.
My set of classes (http://www.dlugosz.com/Repertoire/refman/Classics/Smart%20Pointers%20Overvie...), published over ten years ago, has similar features. My class "baro" is like your weak_pointer.
I recall a threading issue where one thread is dropping the last owned reference at the same time another thread is realizing a weak_pointer. The first decrements the refcount to zero, and the second increments it again. Is the object destructed? I'm using a specific mechanism to support this and related features, and I don't see that in your code.
Is the Boost implementation for Windows (32 and 64-bit) robust and lock-free in cases like this? How does it work?
--John
I think this might help: http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm#ThreadSaf... It covers shared_ptr only, though. Regards, Roland
-----Original Message----- I think this might help:
http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/shared_ptr.htm#Thre adSafety
It covers shared_ptr only, though.
Regards,
Roland
I had read that. " A shared_ptr instance can be "read" (accessed using only const operations) simultaneously by multiple threads. Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)" was instructive. That's what I need. But I was specifically wondering about the mix of weak_ptr's. I guess mine is more complicated because it can do lazy copy on write, but still the effect of making the unowned pointer getting ownership at the same time as other threads are releasing all the existing owners was an issue of specific importance. I implemented a "sticky zero" non-blocking counter for the purpose. I want to make sure that the Boost implementation can do this robustly and efficiently, too. And perhaps point out that weak_ptr's need thread issue documentation too. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 18 August 2009, John Dlugosz wrote:
But I was specifically wondering about the mix of weak_ptr's. I guess mine is more complicated because it can do lazy copy on write, but still the effect of making the unowned pointer getting ownership at the same time as other threads are releasing all the existing owners was an issue of specific importance. I implemented a "sticky zero" non-blocking counter for the purpose.
I want to make sure that the Boost implementation can do this robustly and efficiently, too. And perhaps point out that weak_ptr's need thread issue documentation too.
shared_ptr/weak_ptr does modify its reference count atomically. You can't resurrect an expired shared_ptr through a weak_ptr, it will throw or return an empty shared_ptr depending on whether you are using the shared_ptr constructor or weak_ptr::lock. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqKzCcACgkQ5vihyNWuA4W2HQCfV5IrvTt8NEuyY7+gFF9IJCui yEsAoOP56qt3sTjgvHb3DlVTR8Dvj0WN =DY5i -----END PGP SIGNATURE-----
participants (3)
-
Frank Mori Hess -
John Dlugosz -
Roland Bock