Subject: Re: [boost] boost.lockfree update
From: Tim Blechmann (tim_at_[hidden])
Date: 2010-07-24 10:49:45
> 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?
> 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_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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk