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