Find the answer to your Linux question:
Results 1 to 6 of 6
Like Tree3Likes
  • 1 Post By Syndacate
  • 2 Post By henrikau
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Mar 2012
    Posts
    14

    Which process gets spinlock when multiple processes are trying to get


    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.

  2. #2
    Just Joined!
    Join Date
    Mar 2012
    Posts
    14
    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?

  3. #3
    Linux Newbie Syndacate's Avatar
    Join Date
    May 2012
    Location
    Hell..no literally, this state is hell..
    Posts
    192
    Quote Originally Posted by tutika View Post
    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.

    Quote Originally Posted by tutika View Post
    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 .
    tutika likes this.

  4. #4
    Just Joined!
    Join Date
    Mar 2009
    Location
    Norway
    Posts
    67
    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
    Syndacate and tutika like this.

  5. #5
    Just Joined!
    Join Date
    Mar 2012
    Posts
    14
    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?

  6. #6
    Just Joined!
    Join Date
    Mar 2009
    Location
    Norway
    Posts
    67
    Quote Originally Posted by tutika View Post
    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).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •