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

    https://github.com/apache/spark/pull/1083#discussion_r13779775
  
    --- 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 --
    
    This paragraph doesn't make a lot of sense to me. In general it is just 
unlikely for two threads to work on the same rdd partition. However, if we ever 
pass the first if (where it returns None), it already means we are in the 
"unlikely" case.


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