Lock free shared_ptr on gcc, help needed
So, shared_ptr is now lock-free on Windows, but not on the other platforms. We need a portable atomic primitive for that. The only alternative are the internal libstdc++ helpers __atomic_add and __exchange_and_add. But in order to use them correctly, we need to know what their exact semantics are with respect to memory synchronization. To the best of my knowledge, this is not documented anywhere. What do we do now? -- Peter Dimov http://www.pdimov.com
On Thu, Mar 24, 2005 at 05:40:07PM +0200, Peter Dimov wrote:
So, shared_ptr is now lock-free on Windows, but not on the other platforms. We need a portable atomic primitive for that. The only alternative are the internal libstdc++ helpers __atomic_add and __exchange_and_add.
But in order to use them correctly, we need to know what their exact semantics are with respect to memory synchronization.
To the best of my knowledge, this is not documented anywhere.
What do we do now?
From my brief survey of the primitives, the memory synchronisation isn't well defined ... it depends on the particular implementation on a
I can find out if you like - I am using the primitives for the libstdc++ version of shared_ptr so was going to dig into their semantics this weekend and ask on the libstdc++ list. particular platform (the i386 implementations, for example, just use a mutex, so aren't lock-free at all). If the implementation for platform X uses memory barriers then it will be well-defined on platform X. N.B. libstdc++ had a compare_and_swap primitive until a couple of years ago, when it was removed because nothing was using it and it was a headache when porting libstdc++ to new architectures. I'm going to ask about the possibility of resurrecting that compare_and_swap(), otherwise shared_count::add_ref_lock() needs to use a lock. jon
Jonathan Wakely wrote: [...]
N.B. libstdc++ had a compare_and_swap primitive until a couple of years ago, when it was removed because nothing was using it and it was a headache when porting libstdc++ to new architectures. I'm going to ask about the possibility of resurrecting that compare_and_swap(),
Do the right thing and tell'em to introduce atomic<> with IBM style CAS (with msync decorators of course) and etceteras as lowest common denominator (RIP i386). Arch specific stuff (like load_reserved() and store_conditional() member functions) shall be available too (less portability... but global warming matters, they say ;-) ). regards, alexander.
"Peter Dimov" <pdimov@mmltd.net> writes:
So, shared_ptr is now lock-free on Windows, but not on the other platforms. We need a portable atomic primitive for that. The only alternative are the internal libstdc++ helpers __atomic_add and __exchange_and_add.
But in order to use them correctly, we need to know what their exact semantics are with respect to memory synchronization.
To the best of my knowledge, this is not documented anywhere.
What do we do now?
-- Peter Dimov http://www.pdimov.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Could the primitives used by the lock-free shared_ptr be made available from boost threads? It would be helpful for other people writing lock-free code. Robert Zeh
Robert Zeh wrote:
Could the primitives used by the lock-free shared_ptr be made available from boost threads? It would be helpful for other people writing lock-free code.
Probably not, and even if they are made available, it wouldn't be helpful. You can't write correct lock-free code with primitives that have unspecified memory synchronization properties. Well... maybe you can, but most of us cannot. ;-) (Most of us can't write correct lock-free code at all, but that's a different story.)
On Wed, Mar 30, 2005 at 07:08:02PM +0300, Peter Dimov wrote:
(Most of us can't write correct lock-free code at all, but that's a different story.)
I often have problems with meta-programming but rarely with re-enterant programming ;-) Its nice to know that some traditional skills are still in demand! /ikh
Iain K. Hanson wrote:
On Wed, Mar 30, 2005 at 07:08:02PM +0300, Peter Dimov wrote:
(Most of us can't write correct lock-free code at all, but that's a different story.)
I often have problems with meta-programming but rarely with re-enterant programming ;-) Its nice to know that some traditional skills are still in demand!
I thought lock-free stuff is rather new... or is it not? At any rate, to me it is. :o) Reminds me of that joke: the Romanian starts punching his long-time Hungarian friend. "What's wrong with you?" "You guys killed our king!" "But that was 400 years ago!" "Yeah, but I found out only now!!!" Andrei
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
Iain K. Hanson wrote:
On Wed, Mar 30, 2005 at 07:08:02PM +0300, Peter Dimov wrote:
(Most of us can't write correct lock-free code at all, but that's a different story.) I often have problems with meta-programming but rarely with re-enterant programming ;-) Its nice to know that some traditional skills are still in demand!
I thought lock-free stuff is rather new... or is it not?
I remember the CAS instruction from the 68020. Seems to me they must have had some kind of lock-free manipulation in mind when they put that in? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
Alexander Terekhov -
Andrei Alexandrescu (See Website For Email) -
David Abrahams -
Iain K. Hanson -
Jonathan Wakely -
Peter Dimov -
Robert Zeh