-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've got thread_safe_signals working with a single mutex per signal, which is only locked/unlocked once per signal invocation. However, it is causing problems with deletion_test.cpp. The deletion test checks if a slot is able to disconnect another slot which is ordered later in the same signal invocation. From the signals docs: "If a signal/slot connection is disconnected at any time during a signal's calling sequence, the calling sequence will still continue but will not invoke the disconnected slot." 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. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF5uiA5vihyNWuA4URAkWCAKCPm3xLEp6z1K8Nk5Vp8wHVNKkXqwCfZ7Il eL0Axnl/SD/4m6i3j54OnfA= =lSky -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
I've got thread_safe_signals working with a single mutex per signal, which is only locked/unlocked once per signal invocation. However, it is causing problems with deletion_test.cpp. The deletion test checks if a slot is able to disconnect another slot which is ordered later in the same signal invocation. From the signals docs:
"If a signal/slot connection is disconnected at any time during a signal's calling sequence, the calling sequence will still continue but will not invoke the disconnected slot."
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. Regards Timmo Stange
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
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
participants (3)
-
Frank Mori Hess -
Frank Mori Hess -
Timmo Stange