Which lock‑handling strategy should Composer adopt to mitigate latency when multiple installs run concurrently?

Background

Composer creates a temporary lock file (.composer.lock.tmp) during dependency resolution. The file is locked exclusively until the install completes, which blocks any other Composer process that attempts to acquire the lock in the same repository.

Current Behavior

When two or more PHP Composer processes start simultaneously, the first process obtains the exclusive lock, while the others block until the lock is released. Composer does not provide a timeout, retry mechanism, or shared‑read capability for the lock file. This behaviour is not documented in the official manual or issue tracker, and it can cause unpredictable latency spikes in CI/CD pipelines that invoke Composer in parallel.

Unresolved Decision

The core uncertainty is whether Composer should implement a shared or advisory lock that allows multiple processes to read the lock file concurrently while preventing concurrent writes, or whether it should fail immediately, wait, or retry with back‑off when a lock is already held.

Specific Questions

1. Which lock mechanism (exclusive, shared, or advisory) should Composer implement to enable concurrent reads of .composer.lock while protecting against concurrent writes?
2. Should Composer provide a retry or exponential back‑off strategy for lock acquisition to avoid indefinite waits, and if so, what should the timeout policy be?