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

- `Config::acquire_package_cache_lock` — Acquires a lock. May block if another process holds a lock.
- `Config::try_acquire_package_cache_lock` — Acquires a lock, returning immediately if it would block.
- `Config::assert_package_cache_locked` — This is used to ensure the proper lock is being held.

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

- CacheLock
  A held lock guard.
- CacheLocker
  A locker that can be used to acquire locks.
- CacheState 🔒
  The state of the `CacheLocker`.
- RecursiveLock 🔒
  A file lock, with a counter to assist with recursive locking.

## Enums

- BlockingMode 🔒
  Whether or not a lock attempt should block.
- CacheLockMode
  The style of lock to acquire.
- LockingResult 🔒
  Whether or not a lock attempt blocked or succeeded.

## Constants

- CACHE_LOCK_NAME 🔒
  The filename for the `CacheLockMode::DownloadExclusive` lock.
- DOWNLOAD_EXCLUSIVE_DESCR 🔒
- MUTATE_EXCLUSIVE_DESCR 🔒
- MUTATE_NAME 🔒
  The filename for the `CacheLockMode::MutateExclusive` and `CacheLockMode::Shared` lock.
- SHARED_DESCR 🔒

## Functions

- maybe_readonly 🔒
  Returns whether or not the error appears to be from a read-only filesystem.