In Sharding we have a requirement to be able to lock some object by name (where an object is database or collection) for short period of time, while we perform some in-memory modifications on that object.

These are much lighterweight locks than our current DB/Collection locks in that we will never do blocking operations under than and also they do not require 2-phase locking.

The current RESOURCE_MUTEX is unsafe to be acquired with a manually constructed string that contains the DB or Collection name in it, because the hash to string resolution relies on the hash mapping to a string name.

I am realising now that this is not correct, because RESOURCE_MUTEX's implementation (and its logging specifically) assumes that the ResourceMutex class is in control of generating the ResourceIds, rather than just taking the hash of the string that's passed as the resource name. Thus, right now these usages violate the implicit contract of RESOURCE_MUTEX.

Given the requirements above, we still need to be able to lock something by name and we don't care about hash collisions.

For this purpose I would like to extend the lock manager with the following resource types with more stricter semantics:

• TopResourceMutex: Not allowed to be locked by random string and the lock manager controls what hashes get assigned to each one; the only way to use it through a TopLevelResourceMutex class; can only be the first lock acquired; The use case is to disallow for example two instances of the same command to run concurrently;
• ResourceMutex: Same as the current resource mutex; cannot do blocking operations while holding it;
• NamedLock: Allowed to be locked by random string; Not interruptible and no Global/DB/Collection locks can be taken after it (i.e., it must be at the bottom of the hierarchy)