Re: [boost] threadpool lockfree_channel

Subject: Re: [boost] threadpool lockfree_channel
From: Tim Blechmann (tim_at_[hidden])
Date: 2009-03-16 06:55:26

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?

best, tim

-- 
tim_at_[hidden]
http://tim.klingt.org
There's no such entity as "most people". These are generalities. All
generalities are meaningless. You've got to pin it down to a specific
person doing a specific thing at a specific time and space.
  William S. Burroughs