CODEWITHSUNDEEP
clinuxlinux-kernel
Jun
Jun

Reputation: 426

Is spinlock required for every interrupt handler?

In Chapter 5 of ULK the author states as follows:

"...each interrupt handler is serialized with respect to itself-that is, it cannot execute more than one concurrently. Thus, accessing the data struct does not require synchronization primitives"

I don't quite understand why interrupt handlers is "serialized" on modern CPUs with multiple cores. I'm thinking it could be possible that a same ISR can be run on different cores simultaneously, right? If that's the case, if you don't use spinlock to protect your data it can come to a race condition.

So my question is, on a modern system with multi-cpus, for every interrupt handler you are going to write that will read & write some data, is spinlock always needed?

Upvotes: 10

Views: 3567

Answers (5)

millise
millise

Reputation: 1

section 4.6 of Understanding the Linux Kernel, 3rd Edition by Marco Cesati, Daniel P. Bovet told you the answer. Actual interrupt handler is process by handle_IRQ_event. irq_desc[irq].lock prevent concurrently access to handle_IRQ_event by any other CPU.

Upvotes: 0

srikant-ritolia
srikant-ritolia

Reputation: 51

No spinlock is not always needed in interrupt handler.

Please note one thing first - When an interrupt of a particular device occur on interrupt controller, that interrupt is disabled at interrupt controller and hence on all the cores for that particular device. So, the interrupt of same device cannot come on all the CPU simultaneously. So in normal case there wont be any spin lock required as the code would not be re-entrant.

Though there are 2 cases below in which spinlock is needed in interrupt handler.

  1. Please note, when an interrupt comes from a device and IRQ line, that cores disables all other interrupt on that core and also for that device interrupt on other core also. Interrupt from other devices can comes on other core.

So there can be a case in which, same interrupt handler is registered for different devices. for eg:- request_irq(A,func,..); reqest_irq(B,func,..); for device A interrupt handler func is called. for device B same interrupt handler func is called. So, a spinlock should be used in this case to prevent raise condition.

  1. When same resource is being used in interrupt handler and also some other code which runs in process context. For eg:- there is resource A So there can be a case in which one cores runs in interrupt mode, the interrupt handler and is modifying the resource A and other core runs in process context and is also modifying the same resource in some other place. So to present raise condition for that resource we should use spin lock.

Upvotes: 0

gby
gby

Reputation: 15218

Clarification: as per CL. remark below - the kernel makes sure not to fire the interrupt handler for the same interrupt but if you have multiple registrations of the same interrupt handler for multiple interrupts than the below answer is, I believe, correct.

You are right that the same interrupt handler can run concurrently on multiple cores and that shared data needs to be protected. However, a spinlock is not the only and certainly not always the recommended way to achieve this.

A multitude of other synchronization methods, from per-CPU data, accessing shared data only using atomic operations and even Read-Copy-Update variants may be used to protect the shared data.

Upvotes: 4

CL.
CL.

Reputation: 180070

While executing interrupt handlers, the kernel explicitly disables that particular interrupt line at the interrupt controller, so one interrupt handler cannot be executed more than once concurrently. (The handlers of other interrupts can run concurrently, though.)

Upvotes: 7

a.saurabh
a.saurabh

Reputation: 1231

If the critical data is shared b/w the interrupt handler and your process (may be a kernel thread) then you need to protect your data and hence spinlock is required.A common Kernel api for spinlock is : spin_lock(). There are also variants of these api e.g. spin_lock_irqsave() which can help avoiding the deadlock problems which one can face while acquiring/holding the spin locks.Please go through the below link to find details of the subject: http://www.linuxjournal.com/article/5833

Upvotes: -1

Related Questions