Gian-Carlo Pascutto (gcp.delete@this.sjeng.org) on January 6, 2020 7:00 am wrote:
>
> What to do if you need cross-platform code though?

I agree it's a problem. As you say, the common standard interfaces have issues, although I suspect that underlying lock performance is seldom the primary one. They may be a bit too generic and perform worse than a simpler locking model would due to that.

But yes, they can have other show-stopper issues, in that they force unknown sizes and alignment on you.

It probably wouldn't be a huge problem for most projects to have a (small) OS-specific library layer. You almost invariably need to have something like that even for the simplest cross-platform code anyway, unless "cross-platform" is very limited and ends up being something like "minimal posixy support".

So if all you really want to do is have a mutual exclusion lock, and your main issue is about size of the lock, then I agree that it would likely be very nice to have some nice independent library project that gives a reasonable lock that fits in a 32-bit entity and just provides simple versions for all the main environments.

It would probably not be all that hard to get something that is cross-platform by getting a couple of platform people to provide a working version for their code. It should be fairly trivial to do on Linux with futexes, if all you really want is just basic mutual exclusion like a spinlock (just without the spinning). You generally can find existing code in existing open source projects.

I assume that the equivalent Windows thing would be trivial to cook up for a Windows person too. So you'd have to use some effort to find a person who knows locking for each platform, but every platform does have some core lock that is small.

Somebody who is interested in starting such a project might be able to set something up mainly by just googling different peoples system-specific libraries and just acting as a gathering point.

That said, I do suspect that the easy portable solution to your "the portable system locks are too big" is to use just a hashing wrapper around an array of the bigger portable ones as you mention. Then the per-data structure locks have zero size (use the address of the data structure as the input to the hash) outside of that statically allocated array.

Hashed locks have their own issues, of course, particularly wrt lock ordering (but they can also make for bad cache access patterns, so there can be those kinds of fundamental reasons to avoid them - but with a smaller array you might actually get better cache behavior in some cases).

If you ever lock multiple objects at the same time, you obviously then need to take the hashing into account when doing the ordering to avoid any ABBA deadlocks, and if your locking order is about the data structure hierarchy you will need to figure something clever out, but I suspect that for a lot of common simple cases that isn't a huge deal.

Maybe support different "lock classes" by just having multiple arrays of locks, so that locking one type of data structure doesn't affect another kind (if you can't guarantee lock ordering statically).

Linus