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 ...
tim
-- tim_at_[hidden] http://tim.klingt.org 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