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

    https://github.com/apache/spark/pull/1083#discussion_r13781775
  
    --- Diff: core/src/main/scala/org/apache/spark/CacheManager.scala ---
    @@ -128,4 +76,89 @@ private[spark] class CacheManager(blockManager: 
BlockManager) extends Logging {
             }
         }
       }
    +
    +  /**
    +   * Acquire a loading lock for the partition identified by the given 
block ID.
    +   *
    +   * If the lock is free, just acquire it and return None. Otherwise, 
another thread is already
    +   * loading the partition, so we wait for it to finish and return the 
values loaded by the thread.
    +   */
    +  private def acquireLockForPartition(id: RDDBlockId): 
Option[Iterator[Any]] = {
    +    loading.synchronized {
    +      if (!loading.contains(id)) {
    +        // If the partition is free, acquire its lock and begin computing 
its value
    +        loading.add(id)
    +        None
    +      } else {
    +        // Otherwise, wait for another thread to finish and return its 
result
    +        logInfo(s"Another thread is loading $id, waiting for it to 
finish...")
    +        while (loading.contains(id)) {
    +          try {
    +            loading.wait()
    +          } catch {
    +            case e: Exception =>
    +              logWarning(s"Exception while waiting for another thread to 
load $id", e)
    +          }
    +        }
    +        logInfo(s"Finished waiting for $id")
    +        /* See whether someone else has successfully loaded it. The main 
way this would fail
    +         * is for the RDD-level cache eviction policy if someone else has 
loaded the same RDD
    +         * partition but we didn't want to make space for it. However, 
that case is unlikely
    +         * because it's unlikely that two threads would work on the same 
RDD partition. One
    --- End diff --
    
    Yeah, this comment already existed and it wasn't exactly clear to me why we 
needed the lock in the first place. However, assuming the unlikely case that 
two threads do work on the same partition, it is technically possible for a 
race condition to occur where the block is kicked out of memory immediately 
after the other thread released the lock. In this case when we try to `get` the 
block we will return `None`.


---
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.
---

Reply via email to