Subject: Re: [boost] Review Request: boost.lockfree
From: Tim Blechmann (tim_at_[hidden])
Date: 2009-11-24 13:15:55
-----BEGIN PGP SIGNED MESSAGE-----
>> boost.lockfree provides:
>> * boost::lockfree::fifo, a lock-free fifo queue
>> * boost::lockfree::stack, a lock-free stack
> I assume your data structures allow multiple concurrent writers.
> Have you considered benchmarking them against implementations that don't
> allow concurrent writes, since those are usually simpler?
these data structures are lock-free multi-writer/multi-reader
implementations. i suppose, the algorithm could be simplified for single
writers, but i haven't done so ...
> If they're not as fast, it might be interesting to provide both. In any
> case, I think benchmarks would be required to properly review that
> library since it is in such a performance sensitive domain.
well, one aspect of lock-free data structures are throughput, the other
one is worst-case execution time ... the implementation currently
focuses on worst-case execution time ... e.g. intel's tbb contains a
concurrent_queue class, which uses spinlocks ... it probably has a
higher throughput, but its api calls are blocking
> I also see your library provides an "atomic_int" type, which is a subset
> of what the standard library provides in C++0x.
> I believe there already are projects for implementing the standard
> atomic int types within Boost, anyone has some info on this?
the whole low-level part of boost.lockfree should be replaced, once a
c++0x-style atomic library is available ...
The first question I ask myself when something doesn't seem to be
beautiful is why do I think it's not beautiful. And very shortly you
discover that there is no reason.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk