Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #5446 > unrolled thread

Mutexes are faster then spinlocks

Back to article view | Back to comp.programming.threads

Contents

  Mutexes are faster then spinlocks Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-05 15:50 +0000
    Re: Mutexes are faster then spinlocks Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 17:43 +0100
      Re: Mutexes are faster then spinlocks Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 17:53 +0100

#5446 — Mutexes are faster then spinlocks

https://github.com/Amanieu/parking_lot/issues/201

"This blog post Mutexes Are Faster Than Spinlocks generated a reddit
discussion about lock implementatons. This made some users benchmark
parking_lot on windows and some results shown are very problematic,
others could just be better (since parking_lot is always faster than
spin on linux and mac, but not on windows for some reason).

I did not run this benchmark since I don't currently have windows
installed, but since the user hadn't filed an issue I decided to post it
here, their comment was:
https://www.reddit.com/r/rust/comments/ejx7y8/blog_post_mutexes_are_faster_than_spinlocks/fd31um3/
"

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [next] | [standalone]

#5447

The issue with spinlocks is that spinlocks would theoretically make
sense if there's a high degree of contention and the locks are held
very shortly so that - theoretically - spinning might win. But if
there's a high degree of contention it would be rare that a single
thread might win on spinning. So the likehood of going to sleep in
this case is very high and you can drop spinning.
But spinlocks are of course inevitable in the kernel in cases of
contention between code-parts that run with disabled scheduler,
f.e. when a thread with disabled scheduler contends on a resource
with an interrupt which might also contend on that resource.

[toc] | [prev] | [next] | [standalone]

#5448

This is rather stupid:
https://docs.microsoft.com/de-de/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionandspincount

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web