#528 Deadlock with RO/RW locks and OpalMixerEndPoint::m_infoMutex

[Valeriy V. Argunov]

1. One thread simply tries to get RW lock on OpalCall.

2. Another thread gets ReadOnly lock on the OpalCall and calls OpalManager::MakeConnection -> OpalMixerEndPoint::MakeConnection, and tries to lock m_infoMutex there:

PWaitAndSignal mutex(m_infoMutex);

1. SIP Pool thread receives SIP INVITE, calls OpalManager::OnIncomingConnection -> OpalManager::MakeConnection -> OpalMixerEndPoint::MakeConnection and locks m_infoMutex.
   Then it creates OpalMixerConnection and calls OpalMixerNode::AttachConnection -> OpalMixerEndPoint::OnNodeStatusChanged -> SIPEndPoint::OnConferenceStatusChanged -> OpalMixerEndPoint::GetConferenceStates -> OpalMixerNode::GetConferenceState where it tries to enumerate m_connections with ReadOnly mode.

So thread 1 wait for the thread 2, thread 2 waits for the thread 3, and thread 3 waits for the thread 1.

Why does the thread 3 wait for the thread 1? Thread 1 simply waits for the RW lock, it doesn't have it yet.

[Valeriy V. Argunov]

It seems like the RO lock blocks other RO locks. I'll try the revision without std::atomic support.

[Valeriy V. Argunov]

The same issue with rev. 32815.

[Valeriy V. Argunov]

We've found that the bug is with PTLIB RW locks.
We'll create a new ticket with test code.

[Robert Jongbloed]

This is just a form of deadlock, and not really caused by the ReadWriteMutex implementation. That implementation is "text book", has been used for over a decade, and I am EXTREMELY unwilling to change anything significant in it. If it has the limitation you have indicated, then so be it.

[Robert Jongbloed]

I have examined several implementations and algorithms for read/write mutexes and they all have the same problem. Bottom line is this a variant of the A/B, B/A locking issue. So, is up to the user of the PReadWriteMutex to avoid.

I have tweaked the code to hopefully avoid the problem.