Re: [Boost-users] [signals] thread-safe post-disconnect() cleanup

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-02-23 18:10:18

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

On Friday 23 February 2007 17:16 pm, Peter Dimov wrote:
> My initial iteration of this hypothetical design would also incur
> several shared_ptr/intrusive_ptr copies on operator() to address the
> thread safety issues in the most obvious "snapshot" way, that is, the
> signal invokes the slots that were connected at the time operator() was
> called. Subsequent concurrent modifications to the slot container do not
> affect the invocation in progress. This has the advantage of being
> highly scalable and deadlock-resistant.
>
> Such an approach may turn out to not be acceptable, though, given that
> the majority of signal benchmarks place heavy emphasis on operator()
> calls.

Actually, since we started dropping all locks before running a slot, it has 
occurred to me that per-slot locking no longer buys us much 
concurrency-wise.  Getting rid of the slot locks would require creating a 
list of unblocked slots at the beginning of signal invocation while 
holding the (only) mutex, before running any slots.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF33Rb5vihyNWuA4URAghdAKCxz1ja1Pbst1SaWGa5Ao8LRr1ANwCgtavD
FncsSdKcdrBExnsangaoCww=
=enpX
-----END PGP SIGNATURE-----