我从文档中读到，在RELEASE_LOCK从持有锁的连接调用之后分发由许多连接请求的锁的行为是未定义的。我很好奇：假设我有一个p1请求锁定的过程，GET_LOCK("lock", 0);以便对该过程的多次调用不会相互干扰。该过程在终止之前释放锁。我有另一个程序p2使用GET_LOCK("lock", 10);.
假设有大量对 的调用p1，并且在中间的某个地方p2被调用，如下所示：
...
CALL p1();
CALL p1();
CALL p2();
CALL p1();
#lock released here from first p1() call: who gets it?
...
理论上，第二个过程不应该受到太大影响：它等待锁被释放，因为GET_LOCKinp1的超时为 0，p2应该是唯一一个在释放时请求锁的过程。但是，我认为我不能期望这种理想的行为是真实的。GET_LOCK从第一个过程开始，当然会花费一些小但非零的时间，并且由于锁不是按请求顺序分配的，是否有可能将锁传递给连续调用p1并p2必须等待？