[Boost-users] [Review] Review results for Lockfree

Subject: [Boost-users] [Review] Review results for Lockfree
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-08-22 21:13:46

All,

The review for the Lockfree library written by Tim Blechman started July
18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO.
All authors votes YES, some made additional requests. Overall, the verdict
of the community was clear:

    Tim Blechmann's Lockfree library is ACCEPTED

The discussion was lively and it touched on several points.

Design
------
The design of the library is sound, the API is usable. Except for naming
issues (discussed below) almost no comments have been made on how to change
it. 

People reviewing the library would like to see a more modular approach to
lockfree data structures in general, possibly by exposing building blocks or
by utilizing policies. The general interest was to have a more diverse set
of data structures available, such as a lock-free linked list or bounded and
fixed-sized data structures.

Atomics Library
---------------
As the initial review announcement stated, Lockfree depends on an external
Atomics library, which has to be separately reviewed in order to get into
Boost as a first class library. There has been some discussions whether
Lockfree could be accepted without Atomics being reviewed. Others suggested
Lockfree may be reviewed and added to Boost SVN only after Atomics got
reviewed (this was mentioned in the review announcement as well).

After all those discussions and based on the wide interest Lockfree data
structures have, I'd suggest to add the current Atomics library as an
implementation detail to Lockfree. Special handling of compilers which
already have implemented std::atomics has to be added to Lockfree, though.
In this case Lockfree should use the atomics from the stdandard library.

Naming
------
The consensus was that the naming of the reviewed data structures has to be
changed. The names should be either fifo and lifo or queue and stack. AFAIK,
Tim already addresses this point.

Documentation
-------------
The consensus of almost everybody referring to the documentation was that it
needs more work. Here is a short (but non-exhaustive) list of things being
mentioned:
 - It lacks rationale and information about the implementation
 - The class synopsis of the data structures should be accessible from the
"Reference" page. 
 - Make non-thread-safe parts more explicit (fifo::empty is described as
non-thread-safe)
 - Document exception guarantees
 - More information needed on internals, the design, and rationale

I would like to thank all who participated in the discussions.

Regards Hartmut
---------------
http://boost-spirit.com