flewkey/cuberite-2a
1
0
Fork 0
Code Releases Activity

Added an elaborative comment on the deadlock prevention code

Browse Source 
(FS #375)

git-svn-id: http://mc-server.googlecode.com/svn/trunk@1597 0a769ca7-a7f5-676a-18bf-c427514a06d6
This commit is contained in:
madmaxoft@gmail.com 2013-06-16 08:51:05 +00:00
parent 360c579105
commit 588d4dc907
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
source/ClientHandle.cpp
View File

@ -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: // Data is received from the client, hand it off to the protocol:
if ((m_Player != NULL) && (m_Player->GetWorld() != NULL)) 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()); cWorld::cLock(*m_Player->GetWorld());
m_Protocol->DataReceived(a_Data, a_Size); m_Protocol->DataReceived(a_Data, a_Size);