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