Currently when coursemodinfo cache uses 2 stores (i.e. a shared store and a local store) it will obtain a lock when setting the shared store cache into the local store due to requirelockingbeforewrite.

This can become an issue for the purge_course_*_cache functions that acquire a lock before get_implementation tries to acquire a lock due to requirelockingbeforewrite, creating a wait on a lock that won't release.

Case:

1. User is on a course page
2. Something happens that changes the coursemodinfo cache version
3. User tries to change a section name inplace
4. Service calls a frontend that doesn't have the most current coursemodinfo cache
5. purge_course_section_cache_by_id acquires a lock before calling $cache->get_versioned
6. Further in the code get_implementation finds the local cache store doesn't have the correct cache version, deletes it, then checks the next store (the shared store), finds the correct version and tries to set it in the local store
7. Because requirelockingbeforewrite is set for coursemodinfo it will try to acquire a lock before set_implementation is called
8. Because of 5. we are now waiting to acquire a lock that we already have
9. get_lock will eventually timeout and the service call will complete
10. The user will see the section name has now updated after a long time (depending on the timeout)
11. Due to the service call taking a long time because of to the cache lock the user cannot do anything else because of the session lock

Simple fix would be to check the lock state before we try to acquire the lock in 7.