Concurrency

Every mpm command fans out over the managers it selected and drives them at the same time. That is where most of the speed comes from: an mpm outdated on a machine carrying a dozen managers costs about as long as its slowest one, rather than the sum of all twelve.

Two things bound that parallelism: how many managers you let run at once, and the handful that reach a backend some other manager reaches too.

How many run at once

--jobs caps the number of managers running concurrently. It takes a count, or one of two keywords: auto, the default, is one fewer than the machine’s logical CPU cores, leaving one free for mpm itself and for the system; max is all of them. --jobs 1 runs the managers one after another.

Two situations ignore that setting and run sequentially anyway. A batch of one manager has nothing left to parallelize. And --verbosity DEBUG streams every manager’s raw output line by line, where interleaving a dozen of them would scramble the narration the flag exists to produce.

What each command spreads

• ✅ every selected manager runs at once.

• 🔒 every selected manager runs at once, except those queueing on a shared backend, which take turns.

• ⛓️ one manager at a time, whatever --jobs says.

Command	Concurrency
mpm cleanup	🔒
mpm doctor	🔒
mpm dump	✅
mpm install	🔒
mpm install <untied package>	⛓️
mpm installed	✅
mpm orphans	✅
mpm outdated	✅
mpm remove	🔒
mpm restore	🔒
mpm sbom	✅
mpm search	✅
mpm sync	🔒
mpm upgrade	🔒

Managers run in parallel; a single manager’s own packages do not. An mpm remove pkg-a pkg-b drives brew and cargo at the same time, but hands pkg-a and pkg-b to brew one at a time. No package manager is safe to invoke twice at once against its own state.

The one command that parallelizes nothing is an mpm install naming a package you left untied to a manager. That install is a priority search: try the managers in order and stop at the first one carrying the package, which cannot be answered by running them all at once. mpm notes at INFO when an explicit --jobs is ignored for this reason. Tie the package to a manager, with --brew or with a purl like pkg:brew/curl, and the install joins the 🔒 row above.

The subcommands that drive no package operation of their own are left out of the table: there is nothing for them to spread.

Shared backends

Two managers are normally independent processes over disjoint state, which is what makes running them together safe. The exception is the group below: each of these drives a backend that another manager in the pool drives too, so the two queue on one lock.

mpm never lets two members of the same family mutate at the same time. Each waits for the previous one, even at a higher --jobs, while managers outside the family keep running in parallel.

        ---
config:
  sankey:
    height: 600
    showValues: false
    width: 800

---
sankey-beta

Serialized managers,pacman database,7
Serialized managers,RPM database,5
Serialized managers,dpkg lock,5
Serialized managers,conda environment prefix,3
Serialized managers,Homebrew update lock,2
Serialized managers,Scoop tree,2
Serialized managers,pkg install database,2
pacman database,pacaur,1
pacman database,pacman,1
pacman database,pamac,1
pacman database,paru,1
pacman database,pikaur,1
pacman database,trizen,1
pacman database,yay,1
RPM database,dnf,1
RPM database,dnf5,1
RPM database,urpmi,1
RPM database,yum,1
RPM database,zypper,1
dpkg lock,apt,1
dpkg lock,apt-mint,1
dpkg lock,deb-get,1
dpkg lock,nala,1
dpkg lock,pacstall,1
conda environment prefix,conda,1
conda environment prefix,mamba,1
conda environment prefix,micromamba,1
Homebrew update lock,brew,1
Homebrew update lock,cask,1
Scoop tree,scoop,1
Scoop tree,sfsu,1
pkg install database,pkg,1
pkg install database,ports,1
    

Shared backend	Managers	Why?
pacman database	pacaur, pacman, pamac, paru, pikaur, trizen, yay	they all reach the pacman database (/var/lib/pacman/db.lck), and two of them mutating at once fail to init their transaction
RPM database	dnf, dnf5, urpmi, yum, zypper	they all reach the RPM database
dpkg lock	apt, apt-mint, deb-get, nala, pacstall	they all install through dpkg and serialize on its /var/lib/dpkg/lock
conda environment prefix	conda, mamba, micromamba	they act on one environment prefix and one package cache, and conda honors none of the locks mamba takes on them
Homebrew update lock	brew, cask	they are the same brew binary, and two concurrent brew update collide on Homebrew’s own update lock
Scoop tree	scoop, sfsu	they work on the same ~/scoop tree, sfsu delegating its mutating operations to the scoop binary itself
pkg install database	pkg, ports	ports keeps no registry of its own and registers what it builds through pkg, whose advisory lock on that shared install database refuses a second writer

Every manager the table does not name shares its backend with nothing else mpm drives, and always runs in parallel. Each family member repeats its own constraint in the Concurrency section of its page, so the fact is one click away from wherever you meet the manager.

See also

• Privilege escalation and sudo — why a run that escalates privileges probes the credential cache before fanning out.

• Package managers — the full pool, one page each.

• CLI parameters — --jobs alongside every other global option.