0

Here is a scenario. Let’s say that a kernel task is running on a uniprocessor system with preemption disabled. The task acquires a spin lock. Now it is executing it’s critical section. At this time, what if the time slice available for this task expires and it has to schedule out?

  1. Does the spin_lock have a mechanism to prevent this?
  2. Can it be scheduled out? If yes, then what happens to the critical section?
  3. Can it be interrupted by an IRQ? (Assuming that preemption is disabled)
  4. Is this scenario feasible? In other words, could this scenario happen?

From the kernel code, I understand that the spin_lock is basically a nop on a uniprocessor with preemption disabled. To be accurate, all it does is barrier() I understand why it is a nop (as it is a uniprocessor and no other task could be manipulating the data at that instant) but I still don’t understand how it could be uninterrupted(due to IRQs or scheduling). What am I missing here? Pointers to the Linux kernel code which indicates about this could be really helpful.

My basic assumptions:

32 bit Linux kernel

vinod maverick
  • 670
  • 4
  • 14
user3778271
  • 89
  • 4

2 Answers2

1

Actually spin_lock() disables preemption by calling preempt_disable() before it tries to acquire the lock, so scenario #1, #2, #3 could never happen. From recent source code, spin_lock() eventually calls __raw_spin_lock(), which calls preempt_disable() before calling spin_acquire() to acquire the lock. spin_lock_irqsave() which is commonly used in interrupt context has similar context.

Regarding #3, if the variable is shared between process/interrupt context, you should always use spin_lock_irq()/spin_lock_irqsave() instead of spin_lock() to avoid deadlock scenario.

luke
  • 400
  • 6
  • 15
0

The mechanism that handles time slices expiring is a timer interrupt. The interrupt will set the TIF_NEEDS_RESCHED flag for the process. When returning from the timer's interrupt context back to your critical section, a check will be made whether or not to preempt the process due to the TIF_NEEDS_RESCHED flag. Since preemption is disabled, nothing will happen and it will return to your critical section.

When your critical section is over, the release of the lock will call preempt_enable() to reenable preemption. At that moment another check is done as to whether or not to preempt. Since the TIF_NEEDS_RESCHED flag is set and preemption is now enabled, the process will be preempted.

  1. Spin locks disable preemption.
  2. No, because preemption is disabled.
  3. Yes. There are spin lock versions that disable IRQs to prevent this.
  4. No because spin locks disable preemption.

Spinlocks don't exist on unitprocessor systems anyway because they don't make sense. If a a thread that doesn't own the lock attempts to acquire it, that means that the thread that does own it is currently asleep (only one cpu). So there's no reason to spin wait for something that's asleep. For this reason spinlocks are optimized away in these cases to just a preemption disable so that no other thread can touch the critical section.

Matviy Kotoniy
  • 362
  • 1
  • 13