[boost] Gauging interest in a thread-safe containers library

Subject: [boost] Gauging interest in a thread-safe containers library
From: Eric Greveson (eric_at_[hidden])
Date: 2009-01-13 18:34:28

Hi all,

I've recently been doing some work that required thread-safe
containers (queue, channel) and I found that in addition to these, a
locking_ptr with similar semantics to boost::shared_ptr (except being
thread-safe too) allowed me to perform all my threaded operations
without needing to worry about synchronisation outside the
container/locking_ptr code, and without a major impact on performance
compared to coding locks in a slightly less generic (== paranoid) way.
These have been re-used with some success by others, and a couple of
containers (specifically the queue and channel) seem to be used
commonly enough to be worthy of an inclusion in Boost.Thread or
similar.

This discussion has been had in the past, on this thread:

http://lists.boost.org/Archives/boost/2004/09/71454.php

Someone else mentioned it later, but there doesn't seem to be much
else said here:

http://lists.boost.org/Archives/boost/2005/11/96991.php

I was wondering if there is more interest now, a few years on. Some of
the pros I can think of are:

* Writing correct thread-safe code can be tricky (I messed up the
first time I wrote my queue).
* Use of multithreading is perhaps more prevalent now, with many-core
CPUs, than it was 4 years ago
* Queues / channels in particular are very useful for building
threaded pipelines etc, and more people might be tempted to use such
programming techniques if a safe option was available "out-of-the-box"
* A thread-safe shared pointer provides a lazy but effective way of
synchronising data in many scenarios (my implementation supports the
usual boost::shared_ptr stuff except for get(), -> and *:
dereferencing is provided by calling an acquire() function which
returns a scoped_lock object on which you can call * and ->.The
destructor of the scoped_lock releases the lock.)
* The thread-safe shared pointer means you could use a pop-copy queue
without significant overhead (depending on use)
* The code length for these class templates on a single platform is
actually quite short (a hundred lines of code or so)

Some cons:

* Need to support all the platforms Boost works on
* Not much interest for these containers last time
* More code to maintain
* Questions about how re-usable a synchronised queue is due to
performance worries (I believe this not to be a major problem for a
major class of problems - e.g. pipelining fairly long operations, such
as in image and video processing)

I'm sure I've missed some things, but I'd be interesting in hearing
whether there's a positive or negative reaction to this. I'd be happy
to contribute code for this - it wouldn't be the fastest possible
code, but I believe that robust, lightweight, maintainable code is
better than nothing in this case, even if it's not the very best
lock-free implementation.

Thanks for reading!

Eric