Subject: Re: [boost] boost.lockfree update
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-07-23 16:16:54
On 23 July 2010 14:08, Tim Blechmann <tim_at_[hidden]> wrote:
> hi christian,
> > Fifo:
> > "The fifo class provides a multi-writer/multi-reader fifo, enqueueing and
> > dequeueing is lockfree, construction/destruction has to be synchronized"
> > What does it mean that construction/destruction has to be synchronized?
> > Both these functions can only be called once.
> one shouldn't try to en/dequeue from one thread, while another thread is
> running the constructor/destuctor. maybe it should formulated in a better
> way ...
Operating on a deleted object is always undefined behaviour. I think it's
not related to lockfree datastructures.
> > bool enqueue(T const & t);
> > Shouldn't this function throw an exception if t cannot be enqueued?
> i would prefer not to throw an exception! if a constant-size freelist is
> used, the enqueue operation may fail, although no `error' occurred. i
> this interface
If memory for the operation cannot be obtained, I believe common practice is
to throw an exception. IMO, it does not matter if a fixed size pool is
exhausted or the global heap, since the effect is the same -> a no op.
With current interface I'd need to always check return value for every
enqueue for out of memory conditions, something I don't need to do with any
> > bool empty(void) //warning Not thread-safe
> > I think this function should be removed from public interface if it
> > be implemented in a thread safe manner.
> i would prefer to keep it, but warn about the thread safety. i am also
> thinking about adding thread-unsafe version of enqueue/dequeue/push/pop,
> since they can be implemented in a more efficient way than the thread-safe
> one can think of a use case, that one thread fills a fifo/queue and then
> notifies consumer threads ...
> Would if suffice to add another constructor for that?
fifo(Iterator first, Iterator last)
Then you can have an optimized way of populating the lockfree
container,without adding unsafe member functions.
Something like this comes to mind:
shared_ptr<fifo<int>> work(new fifo<int>(values.begin(), values.end()));
for(int i = 0; i < N_THREADS; ++i)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk