Re: [RFC] improving spinning in adaptive mutexes

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

> This has the risk that programs might be using normal mutexes with the
> expectation that they will block immediately (e.g., to force a context
> switch to another thread sharing the same CPU), and that custom spinning
> based on normal mutexes for the blocking path get different performance
> characteristics.  However, both seem to be insignificant to me compared
> to the likely many uses in which mutexes are just used as-is with the
> assumption that they should just work fine (e.g., I'm not sure many
> developers would experiment with spinlocks or adaptive mutexes).  Are
> there any other reasons that might make adding spinning to normal
> mutexes risky?

>From my experience, one of the big reason is a thread fairness. When
application has a giant lock (likes python, ruby, qemu), mutex/condvar
behavior determin thread switching behavior. and then, it behave as a core
piece of thread scheduling.

When mutex will block immediately, thread is scheduled FIFO order and
each thread have the same scheduled chance. however if introduce spinning,
thread scheculing fairness would break.


Oh, I have to write one important thing. If I understand correctly, current python,
ruby, qemu is wise and no affect from mutex strategy. I only talked about one of
historical background. I'm not sure any application has such naive assumption.
I only talked about some applications need to limit scalability intentionally. (e.g.
for emulate something, for care about poor scripting user, et al) I don't talk about
so big matter.

Thank you.