Re: [Boost-users] [signals] per slot mutexes

From: Timmo Stange (ts_at_[hidden])
Date: 2007-03-01 18:52:35

Frank Mori Hess wrote:

>> Well, that's a problem with creating a list of blocked slots and not
>> with locking, or? I only use a per-signal mutex and it passed (past
>> tense, since the current version won't compile ;)) the deletion test
>> fine. I don't use any cleanup or state checking on the whole list of
>> slots, but a reference count for each slot instead. When that count
>> drops to 0, the slot is finally removed from the list. The slot_
>> call_iterator increases the count before the call and decreases
>> it afterwards to ensure the iterator validity. Connecting and dis-
>> connecting similarly increases/decreases the count.
> 
> That would seem to require some kind of locking, or atomic operations to 
> increment/decrement the reference counts safely?  I was only trying to get 
> rid of per-slot locking to reduce locking overhead. 

The reference count is guarded by the signal mutex in my case, so it's
a simple decrement/increment. Since you're releasing the mutex before
invocation starts, you would need atomic ops there, yes.

My approach can result in horrible performance for concurrent signal
invocations, so I won't say it's the way to go. Per-slot locking will
have similar problems, though. There is some chance of repeated
contention for the sequence of mutexes and that might have a "reso-
nance" effect.

I don't think there's a solution without any such trade-offs, at least
not a portable one. That's another reason why I wanted to have both
options for the ThreadingModel parameter. With trivial slot code,
serialized signal invocations are probably the best performing option,
while with complex slots (or even blocking ones), concurrent invo-
cation would be desirable.

Regards

Timmo Stange