$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Signals2] Using dummy_mutex in a multithreaded program
From: Helge Bahmann (hcb_at_[hidden])
Date: 2010-01-18 13:53:46
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