Re: [boost] boost.lockfree update

Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-07-24 10:49:45

hi edd,

> I'd be very interested in using this library when it's "done". For now,
> I've only skimmed the documentation, but here are some initial comments.

its pretty much `done' 

> I think it would be nice to propagate the links to the data structure
> references up to the contents page. Right now they appear to be 'hidden'
> under introduction.

not sure, how this can easily be achieved with quickbook ... any pointers?

> Specifically speaking about
> http://tim.klingt.org/boost_lockfree/boost/lockfree/fifo.html, now:
> 
> 0. "It uses a freelist for memory management, freed nodes are pushed to
> the freelist, but not returned to the os. This may result in leaking
> memory." Presumably this means memory may not be reclaimed until the fifo
> is destroyed, rather than an indefinite leak?

yes.

> 1. "Limitation: The fifo class is limited to PODs". I really would like to
> be able to use this with arbitrary objects. I'm sure PODs are required for
> good reason, but a rationale somewhere would be greatly appreciated.

it is a limitation of the michael/scott algorithm. if you want to pass non-
pods, you have to use heap-allocated pointers.

> 2. For the is_lock_free() method, it says "Warning: It only checks, if the
> fifo head node is lockfree. on most platforms, this should be sufficient,
> though". Sufficient for what? If the implementation can't guarantee
> lock-free behaviour throughout, I'd simply return false. Lock-free
> (typically) means something very specific, after all.

the c++0x semantics of atomics, provide a per-object member function. all 
implementations thati am familiar with will always either provide lockfree 
cas operations for all atomic<> instances or for no. the current 
implementation will give a hint. otherwise i can simply remove this function 
from the interface ...

> 3. For the empty() method, it says "Not thread-safe, use for debugging
> purposes only". Does this mean calling it might destroy the data
> structure's invariants? Or is it always safe in that regard? In which
> scenarios can it be used, specifically?

calling it may return a wrong result. the data structure is not corrupted.

> In either case, I'd be more specific about what's meant by not
> thread-safe. But presumably it would be possible to write a thread-safe
> version given that dequeue can return false? If so, I'd remove/rename/hide
> this function.

for the fifo, it will never be possible. if so, you would have to load two 
atomic objects atomically, which is impossible ...

tim

-- 
tim_at_[hidden]
http://tim.klingt.org
I must say I find television very educational. The minute somebody
turns it on, I go to the library and read a good book.
  Groucho Marx