From 588d4dc9073d884398a13557267743665f0f16c4 Mon Sep 17 00:00:00 2001 From: "madmaxoft@gmail.com" Date: Sun, 16 Jun 2013 08:51:05 +0000 Subject: Added an elaborative comment on the deadlock prevention code (FS #375) git-svn-id: http://mc-server.googlecode.com/svn/trunk@1597 0a769ca7-a7f5-676a-18bf-c427514a06d6 --- source/ClientHandle.cpp | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'source/ClientHandle.cpp') diff --git a/source/ClientHandle.cpp b/source/ClientHandle.cpp index 9d5bbaeaf..cbe544c1f 100644 --- a/source/ClientHandle.cpp +++ b/source/ClientHandle.cpp @@ -1959,7 +1959,18 @@ void cClientHandle::DataReceived(const char * a_Data, int a_Size) // Data is received from the client, hand it off to the protocol: if ((m_Player != NULL) && (m_Player->GetWorld() != NULL)) { - // Lock the world, so that plugins reacting to protocol events have already the chunkmap locked + /* + _X: Lock the world, so that plugins reacting to protocol events have already the chunkmap locked. + There was a possibility of a deadlock between SocketThreads and TickThreads, resulting from each + holding one CS an requesting the other one (ChunkMap CS vs Plugin CS) (FS #375). To break this, it's + sufficient to break any of the four Coffman conditions for a deadlock. We'll solve this by requiring + the ChunkMap CS for all SocketThreads operations before they lock the PluginCS - thus creating a kind + of a lock hierarchy. However, this incurs a performance penalty, we're de facto locking the chunkmap + for each incoming packet. A better, but more involved solutin would be to lock the chunkmap only when + the incoming packet really has a plugin CS lock request. + Also, it is still possible for a packet to slip through - when a player still doesn't have their world + assigned and several packets arrive at once. + */ cWorld::cLock(*m_Player->GetWorld()); m_Protocol->DataReceived(a_Data, a_Size); -- cgit v1.2.3