Boost logo

Boost :

Subject: Re: [boost] Review Request: boost.lockfree
From: Tim Blechmann (tim_at_[hidden])
Date: 2009-11-24 13:15:55


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> 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 ...

cheers, tim

- --
tim_at_[hidden]
http://tim.klingt.org

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.
  John Cage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksMItkACgkQdL+4qsZfVsvEmQCfW1cUbOxXGVa9ylw51NH7uMKB
bMoAn0B2cq6KUmXuV6KLCtiatwGYg54m
=TxMc
-----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