forked from OSchip/llvm-project
<rdar://problem/11486302>
Fixed a case where multiple threads can be asking to send a packet to the GDB server and one of three things will happen: 1 - everything works 2 - one thread will fail to send the packet due to not being able to get the sequence mutex 3 - one thread will try and interrupt the other packet sending and fail and not send the packet Now the flow is a bit different. Prior to this fix we did: if (try_get_sequence_mutex()) { send_packet() return success; } else { if (async_ok) { interrupt() send_packet() resume() return success; } } return fail The issue is that the call to "try_get_sequence_mutex()" could fail if another thread was sending a packet and could cause us to just not send the packet and an error would be returned. What we really want is to try and get the sequence mutex, and if this succeeds, send the packet. Else check if we are running and if we are, do what we used to do. The big difference is when we aren't running, we wait for the sequence mutex so we don't drop packets. Pseudo code is: if (try_get_sequence_mutex()) { // Safe to send the packet right away send_packet() return success; } else { if (running) { // We are running, interrupt and send async packet if ok to do so, // else it is ok to fail if (async_ok) { interrupt() send_packet() resume() return success; } } else { // Not running, wait for the sequence mutex so we don't drop packets get_sequence_mutex() send_packet() return success; } } return fail llvm-svn: 157751
This commit is contained in:
parent
8a66b71c8f
commit
d9896733c7
|
@ -264,7 +264,11 @@ GDBRemoteCommunication::GetAck ()
|
|||
bool
|
||||
GDBRemoteCommunication::GetSequenceMutex (Mutex::Locker& locker)
|
||||
{
|
||||
return locker.TryLock (m_sequence_mutex);
|
||||
if (IsRunning())
|
||||
return locker.TryLock (m_sequence_mutex);
|
||||
|
||||
locker.Lock (m_sequence_mutex);
|
||||
return true;
|
||||
}
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue