GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
The problem is that each thread is unlocking a mutex it didn't unlock.
\ No newline at end of file
The problem that can occur is that each thread is trying to lock a mutex locked by the other thread. And each time they fail, they unlock their own locked mutex and then lock it again in the next iteration. Each process is actively locking and unlocking their own mutex while trying to get the other's mutex. So each of the threads might end up acquiring one of the 2 resources they need while the other one is still held, failing over and over to acquire both resources in a limited amount of time. This is a livelock.
A way to solve this issue would be to put the locking of both mutexes in a critical section, so that each thread is assured to get both of the mutexes, or none, thus avoiding the other thread to get stuck because one of its required mutexes is locked by another thread (same as the problem of the philosophers).
