Re: [boost] threadpool lockfree_channel

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