Re: [boost] [Review] Lockfree review: today (July 28th) is the last day

Subject: Re: [boost] [Review] Lockfree review: today (July 28th) is the last day
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2011-07-28 12:27:58

Hi All,

Please find my review of boost::lockfree below.

I think that boost.lockfree should be accepted in boost, at least its
"ringbuffer" data structure offers really interesting performance (even
though I understand that pure raw performance as in throughput / latency is
not the main goal).

*- 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
boost::interprocess.

*- What is your evaluation of the implementation?*

My evaluation of the perfomance is not based only on the code review, but
mainly on actual tests for the use cases I am interested in professionally
(sadly not all of them yet).

The coding style as the quality you would expect from a boost library. The
nature of the algorithms make it hard to read though.

My performance measurements can be found in the file attached (code and
CSV output). I focused on throughput tests, I didn't have time for latency
yet.

Basically "ringbuffer" is _very_ fast. It crushes Intel's TBB by a factor
10 on single producer single consumer scenario.

"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). In contrast, TBB took the same amount of time (and I guess
that ideally it should take less time with more threads as long as there are
enough cores for each thread to run). This may be attenuated by the fact
that I did not simulate a workload between each synchronized operation as I
did for the SCSP scenario.

Some have emitted fears that the implementation may have bugs because it's
hard to prove concurrent algorithms. I am pretty sure that ringbuffer and
fifo are bug free as far as "int" is used as the data type.

*- What is your evaluation of the documentation?*
*
*
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 ;).

*- Did you try to use the library?  With what compiler?  Did you have any
**problems?*
*
*
I used the library to write a simple series of test. I used GCC 4.5.2 /
Ubuntu in C++0x mode. I didn't have any problem.
*
- How much effort did you put into your evaluation? A glance? A quick
**reading? In-depth study?*
*
*
I spent about 6/7 hours reading the docs and writing my tests.
*
*
*
- Are you knowledgeable about the problem domain?*

I am not knowledgeable about lock free data structures and algorithm but I
write concurrent applications for breakfast.

About the test code :
  - It IS test code
  - You'll need to install and compile TBB and edit the Makefile for your
local paths.

Regards,

Julien