You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@bookkeeper.apache.org by GitBox <gi...@apache.org> on 2018/01/04 05:28:11 UTC

[GitHub] yzang commented on issue #913: Refactor FileInfo locking and refcounting out IndexPersistenceMgr

yzang commented on issue #913: Refactor FileInfo locking and refcounting out IndexPersistenceMgr
URL: https://github.com/apache/bookkeeper/pull/913#issuecomment-355202205
 
 
   @ivankelly After taking a look at your latest change, I still have some questions. Could you help me understand how your latest change resolve the race condition?
   
   Based on my understanding, the following race condition could still happen:
   1. Current status: FileInfo f is cached in both write cache and read cache, so the refCount=2.
   2. Somehow FileInfo f is evicted from write cache, now refCount = 1.
   3. Thread A call getFileInfo() for read, so it get f from read cache at line 221, it hasn't been able to do tryRetain() yet. Now refCount = 1
   4. Thread B at the same time is evicting f from read cache, in handleLedgerEviction it will call fi.release, in the release() function "if (refCount.decrementAndGet() == 0) {" will decrement the refCount, so now refCount = 0, and "releaseFileInfo(ledgerId, this)" will be called. 
   5. Thread B call fileInfo.markDead(), since refCount ==0 is true, it returns true. So now thread B close the FileInfo f.
   6. Thread A continues, it reach tryRetain with refCount =0, and successfully return true.
   7. Thread A returns the FileInfo which is already closed.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services