Subject: Re: [boost] semi lock-free Signals/Slots
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2013-07-24 04:09:34
On Wed, Jul 24, 2013 at 9:30 AM, Andrew Ho <helloworld922_at_[hidden]> wrote:
> 1. emits are lock-free thanks to atomic shared_ptr's/other atomic
> 2. Only a single writer is allowed at a time, uses a mutex for locking.
> The primary goal is to improve low and no slot-count signal emit
This is very interesting to me. I have two projects, one OSS and the other
shares similar constructs built over boost.signals2.
The oss have a gui part which backend could be reused in concurrent context
a central "hub" for communications from the backend to the outer world.
(I was thinking about proposing this for addition in signal libraries but I
don't know how to replace
the tbb::concurrent_unordered_map which is necessary to implement this)
Here is my oss use case:
(ignore the "source" things, it's specific to my use case)
The unit tests:
(consider event::ProjectOpen and event::EditorOpen like if they were
My closed-source project (a complex game) uses the same system (without the
"source" concept, so a bit simpler)
but is in a more concurrent context, where multiple systems (which can be
running in different threads
either specific or by using a global thread pool - the one from tbb)
Some systems provide such kind of hub in their interface to output messages
or even for forwarding
messages to another system; so it's a complex setup, but is based on this
I'm interested in any way to avoid blocking as much as possible, so it
looks like your solution
is better than signals2 in this aspect.
I read the readme and it looks like the library interface is close enough
to signals2 to
match my use case, so I could just replace signals2 in the implementation
of my "hubs" to try signals3.
However I will wait for some of the missing features before testing it. I
connection and scoped connection to work.
> Design Goals
> The main design goal is observed by what signals/slots are typically used
> 1. Connecting/disconnecting slots is usually not that time critical.
> 2. Most signals either have no slots, or very few slots connected.
> 3. Signals may be invoked from multiple threads, and usually can be
> evaluated asynchronously. It seems like slots usually can be evaluated
> asynchronously, but they could be strongly ordered, too. In any case, only
> forward iteration is required for emitting a signal.
> 4. Emitting should be as fast as possible.
It looks like this matches exactly my closed source project.
I'll follow your work, please notify me when you finish the connection and
so that I can help you test this in real context.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk