Re: [boost] semi lock-free Signals/Slots

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
> operations.
> 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
> performance.
>

This is very interesting to me. I have two projects, one OSS and the other
non-OSS which
shares similar constructs built over boost.signals2.
The oss have a gui part which backend could be reused in concurrent context
and expose
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:
https://github.com/artofsequence/aos-designer/blob/develop/backend/include/aosdesigner/backend/tools/eventdispatcher.hpp
(ignore the "source" things, it's specific to my use case)
The unit tests:
https://github.com/artofsequence/aos-designer/blob/develop/backend/test/eventdispatcher.cpp
(consider event::ProjectOpen and event::EditorOpen like if they were
structs)

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
"hub".
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
need
connection and scoped connection to work.

Also,

====================
> Design Goals
> ====================
> The main design goal is observed by what signals/slots are typically used
> for:
> 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
scoped connection
so that I can help you test this in real context.

Joel Lamotte