[Lldb-commits] [REVIEW] Lock hierarchy order violation in Listener/Broadcaster

[Malea, Daniel]

Hi all,

The next problem Inspector found is a lock hierarchy order violation — that is, two mutexes are locked in different orders in different threads, which can lead to deadlocks. The stack traces of the problem are attached.

TL;DR:
Situation 1: Broadcaster::SignUpListenersForBroadcaster locks m_manager_mutex first and then calls Listener::StartListeningForEvents which locks m_broadcasters_mutex.
Situation 2: Listener::StartListeningForEventSpec locks m_broadcasters_mutex then calls into Broadcaster::RegisterListenerForEvents which locks m_manager_mutex.

If both these things happen at the same time, deadlock can occur.

The fix is not the cleanest; but it works. I am making Listener a friend of BroadcasterManager (the reverse friendship is already implemented). And modifying Lister::StartListeningForEventSpec to lock the manager's mutex before locking its own m_broadcasters_mutex. Although this will cause the mutex to be locked "twice" it should not be an issue as the mutex is initialized to be recursive.

Phabricator link: http://llvm-reviews.chandlerc.com/D706

(Patch also attached)


With this fix applied, the total number of threading problems detected by inspector is now 13 :)

On to the next problems,
Dan
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lldb_lock_hierarchy_violation_report.txt
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130422/b4d4ebb4/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broadcaster_listener_lock_ordering.patch
Type: application/octet-stream
Size: 1020 bytes
Desc: broadcaster_listener_lock_ordering.patch
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20130422/b4d4ebb4/attachment.obj>