Github user andrewor14 commented on a diff in the pull request:

    https://github.com/apache/spark/pull/10705#discussion_r53728024
  
    --- Diff: core/src/main/scala/org/apache/spark/storage/BlockManager.scala 
---
    @@ -805,13 +814,12 @@ private[spark] class BlockManager(
               }
             }
           } finally {
    -        // If we failed in putting the block to memory/disk, notify other 
possible readers
    -        // that it has failed, and then remove it from the block info map.
    -        if (!marked) {
    -          // Note that the remove must happen before markFailure otherwise 
another thread
    -          // could've inserted a new BlockInfo before we remove it.
    -          blockInfo.remove(blockId)
    -          putBlockInfo.markFailure()
    +        if (!blockWasSuccessfullyStored) {
    +          // Guard against the fact that MemoryStore might have already 
removed the block if the
    +          // put() failed and the block could not be dropped to disk.
    +          if (blockInfoManager.lockForWriting(blockId, blocking = 
false).isDefined) {
    --- End diff --
    
    Ohhhh, I think I got it. Let's say you try to put a block `MEMORY_ONLY` but 
there is not enough space, in which case we will call 
`blockManager.dropFromMemory` on that block. This call also acquires the write 
lock and releases the lock in the end. However, the way this whole locking 
thing works is that if I acquire the write lock twice, a single call to 
`unlock` will release both locks, so if that happens we need to acquire the 
write lock again here in this line.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to