N core/Linux will run N threads from "different" process?

[softarts]

i.e.
N core runs Linux
'A' process has M threads,M > N
'B' process has M threads also
will N-1 threads of 'A' run on N-1 core,and the rest one runs one thread of B process?

in this situation ,pthread_spin_lock doesn't make sense.
possiblity the sleeping thread of 'A' hold the resource...???

[Dmitry_Vyukov]

Quoting - softarts

i.e.
N core runs Linux
'A' process has M threads,M > N
'B' process has M threads also
will N-1 threads of 'A' run on N-1 core,and the rest one runs one thread of B process?

in this situation ,pthread_spin_lock doesn't make sense.
possiblity the sleeping thread of 'A' hold the resource...???

Provided that M>N answer to your question does not depend on OS scheduler - some process threads will always be sleeping.

I believe that Linux (as well as Windows) scheduler may schedule basically any combinations of threads, so situation you described is perfectly possible.

Regarding spin locks, first of all what kind of spin lock you are talking about - passive spin or active spin? Active spins make less sense in such situation, because as you said sometimes threads will be just burning CPU senselessly. Passive spins make more sense in such situation, because there will be only small overheads for threads switching, and since many of the threads yielding lock owner will be scheduled mach sooner.

There is another moment. Spin locks have less overhead on fast-path, so probably this will cover the expenses of spinning.

So the short answer - it depends.

[softarts]

Quoting - Dmitriy Vyukov

Provided that M>N answer to your question does not depend on OS scheduler - some process threads will always be sleeping.

I believe that Linux (as well as Windows) scheduler may schedule basically any combinations of threads, so situation you described is perfectly possible.

Regarding spin locks, first of all what kind of spin lock you are talking about - passive spin or active spin? Active spins make less sense in such situation, because as you said sometimes threads will be just burning CPU senselessly. Passive spins make more sense in such situation, because there will be only small overheads for threads switching, and since many of the threads yielding lock owner will be scheduled mach sooner.

There is another moment. Spin locks have less overhead on fast-path, so probably this will cover the expenses of spinning.

So the short answer - it depends.

what's the passive spin you are talking about? seems it will cause thread switch?
does pthread_spin_lock in glibc have this behaviour?

thanks!

[Dmitry_Vyukov]

Quoting - softarts

what's the passive spin you are talking about? seems it will cause thread switch?
does pthread_spin_lock in glibc have this behaviour?

By passive spin I mean sched_yield/pthread_yield/SwitchToThread, i.e. when wait is propogated to the OS, however OS still does not know what thread is waiting for. Yes, it causing context switch if there are other threads which has some work to do.
Regarding pthread_spin_lock, I don't know. But I may conjecture that it uses some mixed technique, i.e. make active spin for some time and then switch to passive.