> If that's the case, then perhaps it's not so much that PAL was broken by design but that the original design merely didn't anticipate threading. I don't thin

> If that's the case, then perhaps it's not so much that PAL was broken by design but that the original design merely didn't anticipate threading. I don't think it's even that. It's simply because the API describes the contract between the kernel and processes, not the kernel and threads. It's a case of determining who is responsible for what. In this case the process is responsible for coordinating file locks with the kernel, not individual threads. From the kernel's perspective, 2 requests to the locking API from different threads still come from the same actor: the process. From the perspective of the locking API threads are a process's private business. A developer failing to understand the abstraction levels in an API is not the fault of the API's design, but it could be caused by documentation.