Boost logo

Boost :

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-03-30 12:31:02


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_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Peter Dimov
> Sent: Wednesday, March 30, 2005 8:08 AM
> To: boost_at_[hidden]
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk