I actually disagree with this -- although cache locations might change, we should make sure we have sensible behavior when people do want to coalesce a cached RDD. For example, a common use case I can imagine is doing a filter or local reduce on a big cached RDD, then coalescing the result of that to be more efficient to deal with. In most cases (e.g. HDFS files) we'll be coalescing non-cached RDDs anyway and only caching after the coalesce.

The synchronized here shouldn't be a problem. The DAGScheduler event loop is single-threaded so it will have no trouble acquiring the lock, not to mention it only acquires the lock once per processEvent() call, not separately on each getPreferredLocs() call.