The document discusses issues with multithreaded use of boost::signals2 in C++, specifically focusing on race conditions related to signal connections and the disconnect method. It proposes solutions including the use of a lifetoken for managing handler lifetimes and introduces a new approach with a library called Wigwag that offers a more efficient signal implementation. Key features of the proposed system include improved encapsulation and simpler client code through the use of populators and blocking disconnect methods.

1. Threadsafe signals in C++
Dmitry Koplyarov, 2016

2. Some remarks about the code in these slides
● The namespace names are omitted
● Sometimes the const references are omitted
● The example code has poor design for simplicity purposes
● The example classes only have methods that relate to signals
● TypePtr is a typedef for shared_ptr<Type>

3. boost::signals2

4. Declaring a boost signal

5. Connecting to a boost signal

6. Invoking a boost signal

7. What about the multithreaded use of
boost::signals2?

8. Two major problems
1. No natural way to connect to a signal and get the object’s state without a race
condition
2. The “disconnect” method does not guarantee that the execution flow is out of the
signal handler right after disconnecting

9. Two major problems
1. No natural way to connect to a signal and get the object’s state without a race
condition
2. The “disconnect” method does not guarantee that the execution flow is out of the
signal handler right after disconnecting

10. The Problem
Let’s implement a StorageManager class that manages removable storages (USB sticks,
DVD disks, etc.)

11. The Problem
There’s a race condition in the client code

12. The Problem
There’s a race condition in the client code

13. Trying to solve it
Apparently, we need a mutex

14. Trying to solve it
Connecting to a signal

15. Trying to solve it
Invoking the signal

16. Drawbacks
● A redundant interface with many degrees of freedom
● The StorageManager object is not actually thread-safe
● Mostly copy-pasted code to connect to any similar signal

17. Two major problems
1. No natural way to connect to a signal and get the object’s state without a race
condition
2. The “disconnect” method does not guarantee that the execution flow is out of the
signal handler right after disconnecting

18. The Problem
Let’s implement a simple MediaScanner class

19. The Problem

20. Trying to solve it
Boost suggests using slot_type::track() method, but we need a shared_ptr to the
tracked object

21. Trying to solve it
Client code

22. Trying to solve it
...and here’s the populating of the “already there” storages

23. WAT?
● Too much code for nothing but creating of a MediaScanner object
● The interaction between MediaScanner and StorageManager objects spread
outside of the MediaScanner class
● Client code is forced to own the MediaScanner object via shared_ptr
● Again, all this code doesn’t make much sense, and is almost the same for all
similar cases

24. Make things easier for the client code
OK, let’s hide all the details inside the MediaScanner class

25. Make things easier for the client code

26. Looks better
Client code

27. Drawbacks
● Requires an internal Impl class
● Still a lot of “almost copy-pasted” code to connect to a signal

28. Trying to get rid of the Impl class
Well, there is enable_shared_from_this template in boost

29. Trying to get rid of the Impl class
But it does not work in the constructor, so we need a separate public method

30. Trying to get rid of the Impl class
Client code

31. Drawbacks
● Client code is forced to own the MediaScanner object via shared_ptr
● Client code is responsible for invoking MediaScanner::ConnectToSignals
● Still a lot of “almost copy-pasted” code to connect to a signal

32. Factory method

33. Factory method

34. Factory method
Client code

35. Drawbacks
● Client code is forced to own the MediaScanner object via shared_ptr
● Still a lot of “almost copy-pasted” code to connect to a signal

36. Designing better signals

37. Designing better signals
Problem:
No natural way to connect to a signal and get the object’s state without a race
condition
Solution:
The mutex and the collection were pretty good, but all that code might be hidden
inside the “connect” method

38. Designing better signals
Problem:
No natural way to connect to a signal and get the object’s state without a race
condition
Solution:
The mutex and the collection were pretty good, but all that code might be hidden
inside the “connect” method
Also:
The way we obtain the object state depends on the state nature. It is different for a
collection state and for a single object state. Thus, we need an abstraction here

39. The Populator

40. The Populator

41. How to use

42. How to use
The signal constructor and the populator

43. How to use
You may use a lambda function as a populator instead of a separate method

44. How to use
Or even a lambda function with an auto argument type if you use C++14

45. How to use
Invoking signal

46. How to use
Client code

47. Problem:
The “disconnect” method does not guarantee that the execution flow is out of the
signal handler right after disconnecting
Solution:
We need a way to mark the handler as “dying” and wait for the end of its
execution if necessary
Designing better signals

48. Problem:
The “disconnect” method does not guarantee that the execution flow is out of the
signal handler right after disconnecting
Solution:
We need a way to mark the handler as “dying” and wait for the end of its
execution if necessary
Also:
The SignalConnection destructor should wait on some object, and the handler
should lock that object for the execution time
Designing better signals

49. The LifeToken
LifeToken
an object that controls the handler lifetime, and has a blocking Release method
LifeToken::Checker
stored inside the handler info and references the LifeToken
LifeToken::Checker::ExecutionGuard
a local object that locks the LifeToken for the handler execution time

50. The LifeToken

51. The LifeToken

52. The LifeToken

53. The LifeToken

54. The LifeToken

55. What is inside the LifeToken?
● Some OS primitive for waiting (I use Mutex in these slides)
● Alive flag
● Lock counter (omitted here to make the code simpler)
● ExecutionGuard constructor should block the OS primitive
● ExecutionGuard destructor should unblock the OS primitive
● LifeToken destructor should wait until the OS primitive is unblocked

56. What is inside the LifeToken?

57. What is inside the LifeToken?

58. What is inside the LifeToken?

59. What is inside the LifeToken?

60. What is inside the LifeToken?

61. So, what does MediaScanner with these
signals look like?

62. New MediaScanner

63. New MediaScanner

64. New MediaScanner
Client code

65. Summary
There are two key features that result in much clearer client code:
1. Populators send the object state via the same handler that is used for further
updates tracking
2. A blocking disconnect method results in better incapsulation, without a need for a
nested Impl class or factory methods

66. Is there a ready-to-use solution?

67. The wigwag library
● A header-only library
● Fast and lightweight signals implementation
● Template policies for threading, exception handling and everything
● Async handlers
● Listeners
https://github.com/koplyarov/wigwag

68. Wigwag vs boost comparison
CPU:
Intel Core i7-3517U @ 1.90GHz
Operating system:
Ubuntu 15.10
https://github.com/koplyarov/wigwag

69. Wigwag vs boost comparison
ui_signal:
The most lightweight wigwag signal version. No threading, no populators, no
handler life control. Great for UI components.
signal:
A default wigwag signal configuration. Suits most developers.
boost:
Signals from boost::signals2 library. Both tracking and non-tracking slot versions
are used in handler comparison.
https://github.com/koplyarov/wigwag

70. Signals comparison
https://github.com/koplyarov/wigwag

71. Signal handlers comparison
https://github.com/koplyarov/wigwag

72. https://github.com/koplyarov/wigwag

73. Questions?

74. Thank you!