Re: [boost] boost.lockfree update

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,
>

Hi Tim,

> > 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
> prefer
> 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
other container.

> > bool empty(void) //warning Not thread-safe
> > I think this function should be removed from public interface if it
> cannot
> > 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
> versions.
> 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?
template<class Iterator>
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:

vector<int> values;
shared_ptr<fifo<int>> work(new fifo<int>(values.begin(), values.end()));
for(int i = 0; i < N_THREADS; ++i)
   start_job(work);

/ Christian