Boost logo

Boost :

Subject: Re: [boost] threadpool lockfree_channel
From: Tim Blechmann (tim_at_[hidden])
Date: 2009-03-16 07:42:58

>>> Suppose there are two threads calling deqeue() concurrently. If there is
>>> an item in the queue, both will proceed identically down to line 137, as
>>> neither thread modifies the queue data before then. Now suppose one
>>> thread (A) gets preempted, but the other (B) proceeds. Thread B will
>>> read next->data and assign it to ret. It will then update head_ with CAS
>>> (which will succeed as no other thread is modifying/has modified the
>>> data structure), and *deallocate the node* at line 141. This will
>>> destroy next->data. Now, when thread A wakes up it will try and read
>>> next->data => reading destroyed object, undefined behaviour.
>> dealloc_node in line 141 does not free the node, but pushes it to a
>> freelist stack ... from my understanding, this leads to an increased
>> memory usage ... allocated nodes are not freed until the fifo is
>> destroyed, but reused for new nodes ...
>> so memory reclamation should be safe ... or am i missing something?
> Your dealloc_node is:
> void dealloc_node(node * n)
> {
> n->~node();
> pool.deallocate(n);
> }
> So the node is destroyed (by the destructor) even if the memory is not
> deallocated.

i see your point ... restricting the use of the fifo queue to PODs
should work around this issue ...


Wherever we are, what we hear is mostly noise. When we ignore it, it
disturbs us. When we listen to it, we find it fascinating.
  John Cage

Boost list run by bdawes at, gregod at, cpdaniel at, john at