Comment 12 for bug 1524007

> It occurs to me that we should be able to open the configuration for
> reading without taking the lock.

In thinking about this I have stumbled on what might be the underlying
cause: there is no ordering when taking locks.

A thread will try to take the lock and then sleep for a short time if it
can't. It'll keep doing this for a few seconds after which it will give
up.

Each time the thread wakes up and finds another thread has the lock,
it's not necessarily the same thread or even the same process that's
holding the lock. It could be a different thread every time, even a
thread that has queue-barged for the lock.

Reads vastly outnumber writes, so adding an open-for-read-only option
that does not require a lock (which is safe because the configuration
file is updated atomically) would work around the problem I describe.
Concurrent writers would still be exposed to queue-barging, but so
infrequent are writes that the problem might never manifest.