I talked to Andrei about this. It IS possible to do this as a std::allocator<> replacement, but I have been led to believe it is not a simple matter. The lock free algo (I have been studying this) is one that seems to be more tailored to specific implementation and less to a general library concept. The problem with the std containers is that they are "too power" and provide many conceptual ways to access the data. The model of how std containers work is very different from the "purposely" heavily constrained access provided with the lock free mechanism. I was thinking it might be useful to write a simple lock free container with a limited interface. With this pattern, one could do something in alignment with lock free, but I am not sure it would be palatable for people as the first thing folks would say is "Hey, that's not a std::vector<>".

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Wednesday, March 30, 2005 8:08 AM To: boost@lists.boost.org Subject: Re: [boost] Re: Lock free shared_ptr on gcc, help needed

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.)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost