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

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2007-03-01 18:29:05

On Thursday 01 March 2007 05:06 pm, Timmo Stange wrote:
> > When the list of blocked slots is created at the beginning of signal
> > invocation, before running any slots, then the signal invocation never
> > notices that a later slot has been disconnected by an earlier slot. 
> > It seems to me the only solutions are to either keep per-slot locking,
> > or to drop the requirement that the signal recognize changes to the
> > connection status that happen while the invocation is in progress.  I
> > don't have a good feel for how important a feature this is.  My
> > inclination is to just keep per-slot locking.
>
> 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. 

-- 
Frank