Which process gets spinlock when multiple processes are trying to get

[tutika]

Hi,
I am trying to understand the spinlock concept. But I have a question on it, if more than one process is trying to get a spinlock which process gets the lock.
e.g.,
Process A -- acquired spinlock on Resource R1
Process B -- spinning on R1
Process C -- spinning on R1
Process A -- released R1 by spin_unlock

Now, which process will get lock for R1 either B or C?
I understand B will acquire lock for R1.

Please correct me if my understanding is wrong. Thanks in advance.

[tutika]

Adding to my previous question,
If Process A runs on processor P1.
Is that only A will run on P1 after acquiring spinlock on R1? or Another process can also run on P1?

[Syndacate]

Hi,
I am trying to understand the spinlock concept. But I have a question on it, if more than one process is trying to get a spinlock which process gets the lock.
e.g.,
Process A -- acquired spinlock on Resource R1
Process B -- spinning on R1
Process C -- spinning on R1
Process A -- released R1 by spin_unlock

Now, which process will get lock for R1 either B or C?
I understand B will acquire lock for R1.

Please correct me if my understanding is wrong. Thanks in advance.

I'm almost positive that it's "random", that is, random as in you as a programmer cannot control which gets it first. So one run it may be "B", the next run, "C" might obtain it first. Not positive, its been awhile since I've dealt with systems like that, but that is what I vaguely remember from shared resource locks . Now if you're modifying the kernel you can run any scheduler you want. Though for the majority of purposes, the majority of kernels, etc., you won't be able to choose, it will deal with it however. I know with Java's critical region handling you cannot.

Adding to my previous question,
If Process A runs on processor P1.
Is that only A will run on P1 after acquiring spinlock on R1? or Another process can also run on P1?

I'm not entirely sure I'm understanding this part right, but:

If these are userland processes, no, even if something has the lock, other, unrelated threads of unrelated processes can context switch on and make use of P1. This is kernel dependent, though, right? I mean somebody can modify a scheduler which implements a run-to-completion algorithm, or some other variation which would let the process finish. Or likewise another scheduler might implement a FIFO scheduler which FORCES process A to be switched outDo note, that most processes won't be allowed to access P1, if they require R1, which A is also using, if you know what I mean (ie. most systems won't let processes be switched on which can modify a locked resource - or at least I've never seen one that can do that).

EDIT:
Shared resources aren't exactly my forte, as you can probably tell, but I think/hope that answers your question .

[henrikau]

A spinlock does not suspend a thread from running (unless it exhausts its budget and is rescheduled), that is the very nature of spinlocks. If you have 3 threads, all competing for the same resource (the lock), once A gets the lock, B and C will, as you correctly points out, spin.

Assuming that you have at least 3 CPUs and that B and C are both running, the moment A releases R1, you have what is called a /Race_condition. You have _no_ way of knowing what thread gets the lock. Needless to say, locks are tricky

[tutika]

Thanks Syndacate and henrikau.
Now, I am clear about my first question.

Coming to my second question.
When A runs on P1 and acquires R1 using spinlock. spin_lock() disables preemption. So, I understand only A will run on P1 and other process cannot run until A goes to sleep/completes its execution. And ideally, we should take care that A will never go to sleep when it holds spinlock. Is it right?

[henrikau]

Thanks Syndacate and henrikau.
Now, I am clear about my first question.

Coming to my second question.
When A runs on P1 and acquires R1 using spinlock. spin_lock() disables preemption. So, I understand only A will run on P1 and other process cannot run until A goes to sleep/completes its execution. And ideally, we should take care that A will never go to sleep when it holds spinlock. Is it right?

You cannot sleep whilst holding a spinlock, the whole point of a spinlock is for it to be _fast_ and thus you should only hold it for a _very_ short time. Sleeping/blocking while you are holding a spinlock is a bug.

(yes, yes, if you use PREEMPT_RT, you get spinlocks that sleep, but that's beside the point).