|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-04-26 22:26:25
On Monday 26 April 2004 09:53 am, David Abrahams wrote:
> So, we're thinking of using the signals library in one of our
> projects, but the lack of thread-safety is a concern for us. What
> issues are preventing Boost.Signals from being made threadsafe?
The biggest issue is granularity. Do we use signal-level locking or
connection/slot-level locking? The former requires few locks, but constrains
the coding style quite a bit, whereas the latter is going to incur a bit of
overhead (a lock for every slot call, disconnect, etc.). The other issue is
correctness w.r.t. deletion of trackable objects, especially when dealing
with the slot call iterators: for instance, consider a simple combiner that
does this:
while (first != last) *first++;
If that "++" happens and first != last is true (because there are more slots
to call), then another thread disconnects all of the signals from first up to
last, then the dereference operator is Bad News. I'm sure there are more
issues, but that's a start.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk