Re: [boost] threadpool lockfree_channel

Subject: Re: [boost] threadpool lockfree_channel
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2009-03-16 07:10:35

Tim Blechmann <tim_at_[hidden]> writes:

> hi anthony,
>
>> First, let's look at Tim's implementation at
>> http://tim.klingt.org/git?p=boost_lockfree.git;a=blob;f=boost/lockfree/fifo.hpp;h=066465af55e8f030100093742c8534b3fbb9ce40;hb=HEAD
>> 
>> 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.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK