On 10/02/2021 14:11, Ben Craig via Liaison wrote:
>> I don't quite understand the explanation though. Is the reason that there is
>> no way to get access to a global lock shard for the whole system so locks
>> need to be embedded so that it works for shared memory across processes?
>
> In the Windows ecosystem, you can have multiple versions of the C and C++ runtimes loaded in a process. Many of the runtimes are not "owned" by the operating system, and upgrade independently from each other. The straightforward implementation of a "global" lock shard would end up with a per-runtime lock shard instead. So long as an atomic variable stays in code that uses a single runtime, that would be fine. As soon as the atomic gets used in a different part of the process though, you would end up with two different locks being used for the same piece of memory. By carrying the lock along with the type, you avoid this problem.

This is also the case on POSIX. Python, for example, loads all its .so
with RTLD_LOCAL and so multiple copies of libstdc++ etc come into the
process.

All the standard libraries have internal mechanisms to handle multiple
copies of themselves and not blow up, with varying degrees of
application. My point is, if they want embedded locks to work globally,
they can do this readily enough, and we don't need to worry too much
about it.

Niall