Skip to main content

Locks and concurrency

Concurrency in AetherFS is layered.

Layer 1: optimistic concurrency​

Some routes accept expected hashes.

Use expected hashes when:

  • you want stale clients to fail safely
  • a route is path- or content-oriented
  • retry after refresh is acceptable

Layer 2: collaboration file locks​

Use collaboration locks when:

  • multiple human or agent actors may edit the same path
  • you want a lease-based lock
  • you want a lock token
  • the workflow is product-facing

Layer 3: POSIX-style locks​

Use POSIX lock routes when:

  • a client is bridging filesystem semantics
  • range locking matters
  • the client already thinks in terms of owners, lock kinds, and flock/funlock behavior

Which one should users pick first?​

For normal product workflows:

  • start with expected hashes
  • add collaboration locks when edits become contested
  • only use POSIX-style locks when low-level filesystem compatibility is actually required

See also Which filesystem route should I use?.