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@klingt.org 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