|
Boost Users : |
From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-11 01:48:45
The modified version of Boost.Signals in the sandbox now compiles and
passes the tests on my setup. Basic thread-safety is also in there,
minus tracking and the combiner/signal-to-signal connection issues
that have been discussed here recently.
The thread-safe version will not support grouping and naming of
slots, so there is a preprocessor flag
"BOOST_SIGNALS_NO_LEGACY_SUPPORT" which changes the template
signature of signalN. If defined, the Group and GroupCompare
parameters are replaced with a ThreadingModel parameter (I
chose to put it there and not after SlotFunction, but that may
change). It defaults to signals::single_threaded which results
in non-thread-safe behaviour. When signals::multi_threaded is
given as an argument, the signal should be thread-safe. That is
for now completely untested, though ;).
As I was curious about the call performance, I ran a simple
test, successively connecting up to 4 slots to the signal
and calling it 10000 - 10000000 times. Here are the results:
# Calls CVS SBL SBNS SBNM
1 10000 0.005 0.003 0.001 0.002
1 100000 0.057 0.037 0.019 0.025
1 1000000 0.582 0.362 0.209 0.269
1 10000000 5.882 3.659 2.073 2.668
2 10000 0.007 0.004 0.002 0.003
2 100000 0.075 0.044 0.027 0.031
2 1000000 0.769 0.461 0.269 0.322
2 10000000 7.668 4.535 2.744 3.274
3 10000 0.009 0.005 0.003 0.003
3 100000 0.095 0.054 0.035 0.038
3 1000000 0.964 0.555 0.360 0.411
3 10000000 9.643 5.538 3.525 4.010
4 10000 0.011 0.006 0.003 0.004
4 100000 0.114 0.061 0.038 0.044
4 1000000 1.155 0.641 0.419 0.451
4 10000000 11.482 6.378 4.124 4.519
CVS = The current CVS HEAD version.
SBL = The sandbox version with legacy support (named slots).
SBNS = The sandbox version without legacy support, single-threaded.
SBNM = The sandbox version without legacy support, thread-safe.
I used Visual C++ 2005 Express SP1 with /O2 optimization on an
Athlon X2 3800+ for these tests. Results are in seconds.
The comparison to the original CVS version is not quite fair, as
I used dynamic linking there and static linking for the rest of
the tests. I just did it to make sure my code was not significantly
slower.
The overhead for thread-safety does not grow with the number of
connected slots, as I use a per-signal mutex and no per-slot
locking. That looks good here, but I'm not yet sure it is the best
solution in the long run. It would be nice to not block the
entire signal for the whole time.
As the new single-threaded implementation is somewhat faster than
the one supporting named slots, I will add a signals::no_name type
that can be used for the Group template argument when legacy
support is enabled. That will result in the faster implementation
being used without losing compatibility to existing code with
grouped slots.
Reports about problems with certain compilers and any kind of other
input would be very appreciated. Don't judge too harshly on the code,
I know it needs a lot of cleanup ;).
Regards
Timmo Stange
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net