[Signals2] Using dummy_mutex in a multithreaded program
Greetings Frank, boosters, Currently using a signal with a boost::signals2:dummy_mutex works well only in single-threaded programs. I'm wondering if it can be made a little more useful. I have an use case with a single global signal, where all slots and connections are setup on program start. Afterwards a bunch of threads are fired, and each of them can call the signal's operator(). There are no more connections added/removed, only signal invocations. According to the workflow described here: http://www.boost.org/doc/libs/1_41_0/doc/html/signals2/thread-safety.html#id... ...it seems that a dummy_mutex should be enough, since the slot list is never modified. It turns out it's not - I'm getting assertion failures in nolock_cleanup_connections() because the _shared_state.unique() requirement is sometimes violated. Because using a real mutex will significantly degrade both performance and concurrency, I'm wondering if this assertion is really necessary. In this case it should be safe to continue even if the uniqueness is violated, because the connection list is never modified. And I think my use case is quite common :) - Peter
Am Monday 18 January 2010 16:18:22 schrieb Peter Petrov:
Greetings Frank, boosters,
Currently using a signal with a boost::signals2:dummy_mutex works well only in single-threaded programs. I'm wondering if it can be made a little more useful.
[...]
Because using a real mutex will significantly degrade both performance and concurrency, I'm wondering if this assertion is really necessary. In this case it should be safe to continue even if the uniqueness is violated, because the connection list is never modified. And I think my use case is quite common :)
not a direct answer to your question, but if signals2 is posing performance problems to you, you might want to check out my alternate signal/slot implementation: http://www.chaoticmind.net/~hcb/projects/libtscb/ It provides the same interface as "signals2", but... - it is always thread-safe (no dummy-mutex mode because there is simply no need to ever do that) - it is three(!) times as fast as thread-unsafe "signals" - it is five(!) times as fast as "signals2" with a real mutex It makes extensive use of atomic operations to achieve that -- for your use-case, it adds an overhead of exactly one pair of atomic inc/dec operations for every notification through the signal over an "open-coded" linked list of boost::function objects. Additionally, it can support a "wait-free" mode where you can activate the signal from an interrupt or similar context (e.g. unix signal handler). Regards, Helge
On Mon, Jan 18, 2010 at 8:53 PM, Helge Bahmann <hcb@chaoticmind.net> wrote:
not a direct answer to your question, but if signals2 is posing performance problems to you, you might want to check out my alternate signal/slot implementation:
http://www.chaoticmind.net/~hcb/projects/libtscb/
It provides the same interface as "signals2", but...
- it is always thread-safe (no dummy-mutex mode because there is simply no need to ever do that) - it is three(!) times as fast as thread-unsafe "signals" - it is five(!) times as fast as "signals2" with a real mutex
It makes extensive use of atomic operations to achieve that -- for your use-case, it adds an overhead of exactly one pair of atomic inc/dec operations for every notification through the signal over an "open-coded" linked list of boost::function objects.
Thanks, Helge. In this specific case I've already solved my issue by writing a minimal signal class which mimics the signals2 interface and implements only what I really need. I'll definitely have your library in mind when the need for something more complex arises. Regards, Peter
participants (2)
-
Helge Bahmann -
Peter Petrov