if we had GSL, you could set this up using finally() or if ConfigurationParser would satisfy BasicLockable one could just use a lock_guard lock{my_config}. This would remove the need for the explicit UnlockRes(my_config)

another issue we have with this, is that in certain functions around the code base, there are instances where there are multiple locks and unlocks

void afunction() {
  lockres(...)
  do_something
  unlockres(...)

  do_something_else

  lockres(..) //again
  doxxxxx
  unlockres(..)
}

unless we go around everywhere refactoring to make those functions use a single lock (there are 64 matches for lockres) and make sure the logic stays the same, I don't think there will be a quick fix for this.

I remember we did something similar before with the database locking by creating a DbLocker class that would do locking on construction and unlocking on destruction. But we were lucky in that instance because the locking and unlocking would occur only once for every function involved.

We can probably keep the old behaviour, but allow newer and refactored code to utilize RAII here.

Besides that, you can always do it like this:

void afunction() {
  {
     std::lock_guard lock(my_config);
     do_something
  }
  do_something_else
  {
     std::lock_guard lock(my_config);
     doxxx
  }
}

which isn't nice, but still a lot better than requiring manual unlock (which is btw. one of the main reasons a lot of our code is not exception-safe)

With emplace_back() you can just pass your arguments into the constructor of the contained type (and save a copy operation):

that describes a situation, but does not name the problem.

if I understood it correctly, then ACL_lists[0] is only checking for Job_ACL, but not for the others like Catalog_ACL or Command_ACL.