Re: [Boost-users] [signals] thread_safe_signals feature-complete

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-18 02:34:07

Gottlob Frege wrote:

> - do you hold any locks DURING the slot call?  That's typically bad,
> since you have no idea what else is locked or what a slot might do, so
> deadlocks abound.

Yes, that is a problem both implementations have right now.

> - do you copy the slot list before running through the list?

Frank's approach has copy-on-write semantics.

> - can I connect/disconnect during my slot call (either disconnect
> myself, or connect/disconnect other calls?  If so, does it happen in
> this signal, or the next one?)

You can do that in both implementations. The behaviour regarding 
connect()s from a slot context differs. Disconnections always work
for the current call, as long as the slot wasn't already passed.

> - as for the 'lock per slot' vs 'lock per signal':
> The solution I've come up with in the past is basically lock per slot,
> but more importantly *temporary* lock per slot.  ie you create (or
> take from a pool) locks as needed, and store them in a "slot -> lock"
> map, so IF another thread also needs the lock for that slot, they
> check the map first, and obtain the same lock for that slot.  Using
> this, if you are careful, in  most cases, you don't actually end up
> creating the lock at all (as you have all the information necessary to
> see contention as it is happening, and create the locks as needed.  ie
> you know which slot is being called, and which slot is concurrently
> being disconnected, and only lock if they are the same - which means
> don't lock on the slot call, but AFTER the call, see if another thread
> has come in and is waiting for you to finish.  So actually it is not a
> lock at all, but more of an 'event' (or a 'signal' but that'd be
> confusing).

I'm not sure I completely understood what you're suggesting here.
Trying to avoid the use of the synchronization primitives we have
(few as they are with Boost.Threads) will most likely lead to
trouble. The lock map you're proposing would need to be synched
with a mutex, too, so I don't see the immediate gain.

I currently only use a per-signal mutex and it should be possible
to release that for the duration of the slot call to avoid the
deadlocks you mentioned further above. That doesn't give me the
freedom of concurrent slot invocation, but seeing how many
problems that entails, I'm not sure it is worth the trouble
anymore.

Regards

Timmo Stang