Gian-Carlo Pascutto (gcp.delete@this.sjeng.org) on January 6, 2020 7:00 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 3, 2020 6:05 pm wrote:
> > So what's the fix for this?
> >
> > Use a lock where you tell the system that you're waiting for the lock, and where
> > the unlocking thread will let you know when it's done, so that the scheduler can
> > actually work with you, instead of (randomly) working against you.
> >
> > Notice, how when the author uses an actual std::mutex, things
> > just work fairly well, and regardless of scheduler.
> >...
> >I repeat: do not use spinlocks in user space, unless you actually know what you're doing.
> And be aware that the likelihood that you know what you are doing is basically nil.
>
> What to do if you need cross-platform code though? On Windows std::mutex typically generates a CRITICAL_SECTION
> which IIRC has pretty high overhead.

What do you consider "pretty high overhead"?
For uncontended case EnterCriticalSection() should not be much costlier than direct call + loccked Compare and exchange. LeaveCriticalSection() is likely even cheaper.
In case of contention it is expensive, but it's probably worth the cost vs. homemade alternatives.

For the [very rare in my practice] case where contention is not rare, but the work within critical section is guaranteed to be short, one likely can do better by using critical section initializes with InitializeCriticalSectionWithSpinCount() instead of default InitializeCriticalSection().
I have no idea if it can be accessed from portable C++. But even if it can not, I strongly believe that it is much better to add your own portability wrapper (or good old #ifdef) than to try to implement mutexes of your own.

> Even on Linux I assume the overhead of a standard pthread_mutex_t is
> more than a bool (it needs to at least store a flag to indicate it's a robust mutex or not).
>
> This is annoying for fine-grained locking of small objects. The best suggestion I've seen so far
> was to use hashed mutexes on the object address. Which feels like side-stepping the problem.
>
> Notice that both WebKit and Rust have complete re-implementations too:
>
> https://webkit.org/blog/6161/locking-in-webkit/
> https://docs.rs/parking_lot/0.1.2/parking_lot/
>
> Which have the lock size as a marked point.
>
> But if you're not working on WebKit or in Rust? The default locks in the (C++) library
> suck. Yelling at people to use them serves as much purpose as yelling at windmills.
>
> --
> GCP