$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Talbot, George (Gtalbot_at_[hidden])
Date: 2006-11-22 16:48:07
Hi,
I've attached to this e-mail a working prototype of a wrapper for
shared_ptr that uses a spinlock so that the shared_ptr may be updated
atomically from multiple threads. For example, two threads can both
attempt to set the value of the same shared_ptr, and the last one will
win. This wrapper includes a "compare_and_set" method for performing
lock-free-style "read, copy, attempt swap, repeat" updating to a data
structure, though, of course because the wrapper uses a spinlock, it
isn't truly lock free.
This is a demonstration to see if there's interest out there. It's
useful in my multithreaded application, and I would like to contribute
it to BOOST if it's wanted. There are several issues and questions I'd
want to resolve first, though:
- This prototype only compiles on platforms that have
pthread_spinlock_t available.
- Does weak_ptr<> need to be similarly wrapped?
- If weak_ptr<> needs to be wrapped, that would imply that
enable_atomic_shared_from_this would need to be defined,
as its implementation uses weak_ptr<>.
- Is it possible to use locked compare-and-exchange instructions
to swap the entire shared_ptr<> 8-byte (x86) structure and get
rid of the spinlock? Instead of a bunch of assembly, would it
make more sense to use the prototype atomic_ops library from
Hans Boehm at HP?
http://www.hpl.hp.com/research/linux/atomic_ops/
- There's also Chris Thomasson's refcount library.
http://appcore.home.comcast.net/vzoom/refcount/
- Is anyone else working on something like this? I wouldn't want
to duplicate effort. Specifically, is anyone working on
something that tries to stick to the public interface of
shared_ptr<>?
My major interest in this is that I like the public API of shared_ptr
very much, and since it appears to be headed for standardization, I'm
interested in a variant that's any of:
- A shared_ptr<> implementation with atomic safety guarantees.
- or -
- A wrapper that can be used to wrap shared_ptr<> that has as
close an interface as I can get to shared_ptr<>,
a-la the prototype I've attached.
- or -
- Some other template class that doesn't use shared_ptr<> at
all but shares a most/all of the public API of shared_ptr<>.
Ideally, I want a solution to be lock-free. My next steps will be to
investigate prototypes using (either/both) the HP library and/or the
Thomasson library.
Please let me know if you think I'm going down a dead-end here, or if
you'd like to help.
Thanks.
-- George T. Talbot <gtalbot_at_[hidden]> P.S. Right now I have, in my large multithreaded program, a single typedef, previously using shared_ptr<> when it was single-threaded, currently using atomic_shared<> now that it's multithreaded, that I can replace with something else, so alternate implementations are not drastically hard to try out.