Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Joren Heit (jorenheit_at_[hidden])
Date: 2015-02-06 12:45:10

Thanks Tony for the thorough reply. I had just made sure that signals can
be (dis)connected by multiple threads in a thread-safe manner, but you are
right that there is much more to it. This will be hard to implement I
think, but I'll do my best!

One thing I don't quite grasp yet, is the following. Suppose one thread
disconnects a slot while another fires a signal connected to that slot. You
say that the implementation must make sure that the signal is not fired
after the disconnect-call returns. But won't this be undefined behaviour,
as there is no way of knowing which will grab the lock first?

Joren

On Fri, Feb 6, 2015 at 6:31 PM, Gottlob Frege <gottlobfrege_at_[hidden]>
wrote:

> On Fri, Feb 6, 2015 at 3:15 AM, Joren Heit <jorenheit_at_[hidden]> wrote:
> > Ah, that's a nice one. I wonder why I haven't come across that benchmark
> > myself.
> >
> > I haven't yet made it thread safe, but I have been wondering about this.
> > Does it have to implement the slot-calls (which can itself be
> thread-unsafe)
> > in a safe manner to be considered thread-safe? Or does it only have to be
> > safe with respect to its own data?
> >
>
> For thread safety, the tricky part, but the part you want is two-fold:
>
> 1. You do not want to hold a lock _while_ the slot is being called.
> In general, you never want to hold a lock while calling unknown code
> (ie virtual function, pointer to function, std::function,...), because
> you can't be sure whether that unknown code might grab a lock itself,
> call you back (ie disconnect from within the slot, etc), or whatever,
> which easily leads to hard to track deadlocks.
> 2. If I disconnect a slot, I don't want that slot to fire after the
> disconnection.  Sounds simple, but with threads, what does "after"
> really mean?  Particularly if one thread is calling disconnect while
> another thread is firing the signal?  For our purposes, "after" means
> that the caller, using global flags or whatever, can't tell that the
> slot was called after the call to disconnect returned.
>
> So 1 means no locks or synchronization, and 2 means you need a lock or
> synchronization.
>
> The general way to handle this is by breaking #1, but breaking it as
> narrowly as possible - you still hold a lock while the slot is being
> called, but it is not a lock protecting the whole list of slots, it is
> a lock protecting the currently called slot only.  So you can still
> add/remove slots to the signal, but if you attempt to remove the
> currently running slot, it needs to remove the slot from the list, but
> *if not the same thread as the slot thread* block until that slot is
> finished (otherwise the slot could see itself being called after
> disconnect).
>
> And there are other complications (IIRC) like not using one mutex per
> slot (wasteful), etc.
>
> Tony
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>