Subject: Re: [boost] [Review] Lockfree review: today (July 28th) is the last day
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-07-28 13:05:37
thanks for your review. few comments!
> *- What is your evaluation of the design?*
> Usage of boost.lockfree is simple and elegant. I'd like to see some name
> changed, if I may express my vote I'd say circular_buffer, queue and stack
> in the boost::lockfree namespace. I was thinking about adding an unsafe
> "view" of the structures that would allow normal container operations while
> the main interface would only have "safe" functions.
> I support the proposition to make boost::lockfree work with
after some earlier discussion, i think the best names are queue, stack and
spsc_queue (to make the single-produce/single-consumer safety as explicit as
also enqeueue/dequeue will be renamed to push/pop so that all data structures
share the same interface. (std::queue also uses the names push/pop, so it is
probably the best way to go).
> "fifo" will be more useful in real-time software because it's performance
> is not as scalable as I was expecting: on a 4 core CPU it took more time
> to deal with the same amount of data with 4 threads than with 2 (half
> producers half consumers).
the reason for this is that different threads interfere with each other. i know
of this problem, but also i am not sure if this is a real problem for cases
other than benchmarks. a benchmark will stress the data structures in a rather
unnatural way, but in a real application one probably won't pipe millions of
integers through a queue, but probably the produce threads will spend a lot of
time generating them and the consumer a lot of time processing them ;)
> It's not verbose enough. There's a great deal of work in the code, but as
> it has been stated many times, this is a delicate topic and more help is
> always welcome.
> - What is your evaluation of the potential usefulness of the library?*
> Not developing real time solutions myself, so I can't fully judge. On the
> other hand, a wait free buffer is quite likely to be a very welcomed
> solution for many non real time high performance applications (starting by
> IPC and boost::interprocess ;).
i've spent some time to analyse if using it via boost.interprocess will be
reasonable/feasible. the answer is: it depends on the CPU and the implementation
of atomic<>. if the CPU is supported by boost.atomic, then it is no problem. if
the standard library provides atomic<>, it shouldn't be a problem, either.
however if boost.atomic has to emulate the atomic operations, it will use a pool
of spinlocks (the same spinlock pool that is used for the smart_ptr library).
afaict there spinlocks won't be shared among the different proceses ...
unfortunately there is no way to catch this at compile-time :/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk