Module cargo::util::cache_lock

source ·
Expand description

Support for locking the package and index caches.

This implements locking on the package and index caches (source files, .crate files, and index caches) to coordinate when multiple cargos are running at the same time.

§Usage

There is a global CacheLocker held inside cargo’s venerable Config. The CacheLocker manages creating and tracking the locks being held. There are methods on Config for managing the locks:

Lower-level code that accesses the package cache typically just use assert_package_cache_locked to ensure that the correct lock is being held. Higher-level code is responsible for acquiring the appropriate lock, and holding it during the duration that it is performing its operation.

§Types of locking

There are three styles of locks:

  • CacheLockMode::DownloadExclusive – This is an exclusive lock acquired while downloading packages and doing resolution.
  • CacheLockMode::Shared – This is a shared lock acquired while a build is running. In other words, whenever cargo just needs to read from the cache, it should hold this lock. This is here to ensure that no cargos are trying to read the source caches when cache garbage collection runs.
  • CacheLockMode::MutateExclusive – This is an exclusive lock acquired whenever needing to modify existing source files (for example, with cache garbage collection). This is acquired to make sure that no other cargo is reading from the cache.

Importantly, a DownloadExclusive lock does not interfere with a Shared lock. The download process generally does not modify source files (it only adds new ones), so other cargos should be able to safely proceed in reading source files1.

See the CacheLockMode enum docs for more details on when the different modes should be used.

§Locking implementation details

This is implemented by two separate lock files, the “download” one and the “mutate” one. The MutateExclusive lock acquired both the “mutate” and “download” locks. The Shared lock acquires the “mutate” lock in share mode.

An important rule is that MutateExclusive acquires the locks in the order “mutate” first and then the “download”. That helps prevent deadlocks. It is not allowed for a cargo to first acquire a DownloadExclusive lock and then a Shared lock because that would open it up for deadlock.

Another rule is that there should be only one CacheLocker per process to uphold the ordering rules. You could in theory have multiple if you could ensure that other threads would make progress and drop a lock, but cargo is not architected that way.

It is safe to recursively acquire a lock as many times as you want.

§Interaction with older cargos

Before version 1.74, cargo only acquired the DownloadExclusive lock when downloading and doing resolution. Newer cargos that acquire MutateExclusive should still correctly block when an old cargo is downloading (because it also acquires DownloadExclusive), but they do not properly coordinate when an old cargo is in the build phase (because it holds no locks). This isn’t expected to be much of a problem because the intended use of mutating the cache is only to delete old contents which aren’t currently being used. It is possible for there to be a conflict, particularly if the user manually deletes the entire cache, but it is not expected for this scenario to happen too often, and the only consequence is that one side or the other encounters an error and needs to retry.

  1. A minor caveat is that downloads will delete an existing src directory if it was extracted via an old cargo. See crate::sources::registry::RegistrySource::unpack_package. This should probably be fixed, but is unlikely to be a problem if the user is only using versions of cargo with the same deletion logic. ↩

Structs§

Enums§