mutex vs. spin lock when thread count = hardware parallelism

Question

consider a program with optimal thread count running on dedicated server, so if one thread is locked there're no others (almost) waiting for CPU time. does spin lock provide better performance than mutex in all possible cases in such circumstances?

[EDIT] some explanations: since there's no contention for CPU time between threads, thread can use spin lock w/o any impact on other thread performance. and spin lock doesn't switch to waiting mode that can be heavy enough (at least on windows, idk how it performs on linux)

Answer 1

Your premise isn't very realistic. Maybe your process has the optimum number of threads, the rest to the operating system has many hundred other threads. Some of which might be ready to run and will gladly grab a CPU core when your thread yields. Furthermore, if the thread is about to be blocked, it is likely to happen because of a lock held by one of the other threads in your process. Which might release it during the spin-wait time. The number of threads isn't relevant to that. It thus still make sense to spin-wait.

Answer 2

I think that spinlock will work better in this case, mutexe's aren't really needed unless you are trying to optimize your code and it depends on varying times for I/O etc... You also made a good point about waiting mode.

Answer 3

Spinlock would presumably be more optimal, since there is no transition to kernel. But the scenario is so contrived that I'd suggest never attempting to apply it to real-life code.