[Lldb-commits] [PATCH] Fix deadlock in Listener/Broadcaster::Clear

Pavel Labath labath at google.com
Tue Mar 10 11:11:15 PDT 2015

Good point.

In that case, I see the situation as follows:

a) If thread A calls broadcaster.Clear(), while thread B tries to add a new listener to the broadcaster then two things can happen:

a.i) AddListener gets to execute before the critical section in Clear(): in this case the listener will get added and immediately removed. This is no different from the situation from before the change.
a.ii) AddListener gets to execute after the critical section in Clear(): in this case the listener gets added and stays there. This is also the same behavior.

In either case the situation looks racy (did we want B to be stay registered? or did we want it removed?), and should be resolved by some synchronization between the threads A and B.

b) It get's weirder if thread B tries to add a listener which is already present in the broadcaster. In this case it could happen that the listener is registered in AddListener in thread B and subsequently deregistered by the thread A, even though it will still end up being present in the m_listeners list.

This is not really nice, but I would say that this code was buggy in the first place because it has no way of predicting the end result without additional synchronization. But it is true that without this patch, the end state would at least be completely consistent in any case.

I'll see if I can figure out a way to achieve this without the potential of deadlocking, because calling Clear() from two threads has very well defined semantics and it should not deadlock. (I have seen this deadlock in real life, although it was only exposed by an additional bug).



More information about the lldb-commits mailing list