spinlocks

ashish anand · 08-03-2011, 08:14 AM

why spinlocks are disabled on a uniprocessor system?

kbp · 08-03-2011, 08:38 AM

You should try a little research before asking questions, read the second paragraph here: http://en.wikipedia.org/wiki/Spinlock

sundialsvcs · 08-03-2011, 09:14 AM

"Silly rabbit ... what's a spinlock for?" And, if you know that, "what does a spinlock have to guard against if there is only one CPU?"

ashish anand · 08-03-2011, 11:29 PM

see i know but had a little confusion.I was thinking of a scenario

i have a uniprocessor machine

now one of my kernel threads say A has aquired a spinlock on particular data structure say DS .There can be a situation that it gets scheduled and another thread say B gets scheduled which is operating on the same data structure say DS now since spinlocks are disabled thread B will start operating on DS which can lead to race conditions .Please correct me if I am wrong .I am very new to linux kernel .

Thanx in advance

bsat · 08-04-2011, 12:35 AM

The scenario you have mentioned can not occur with spinlocks.

If Process A holds a spinlock, it can not be taken out of the processor because kernel preemption gets disabled while holding a spinlock.
Even if did get preempted while holding the lock, and process B tries to acquire the lock it will fail as process A would be holding it and Process B would spin endlessly on the lock. Because CPU will be kept busy by the Process B and there is no way for process A to come back and release the lock, leading to a perfect situation of a deadlock.

ashish anand · 08-04-2011, 11:21 PM

hi

the scenario of which I am talking about is on uniprocessor system where spinlocks are disabled so at first A will not be able to lock.
only kernel preemption gets disabled .As kernel preemtion is disabled so a process in user space cannot be scheduled but what if a kernel thread B gets scheduled .what you say.(A and B both are kthreads so will be in kernel context)

bsat · 08-05-2011, 07:25 AM

I am not really clear what exactly you are trying to say.

Quote:

spinlocks are disabled so at first A will not be able to lock

when spinlock is disabled, what are you trying to lock ?

If multiple threads have to access the same data you could protect it using semaphore or use atomic operations. Failing to do so is poor programming and there is nothing that kernel can do for that.

ashish anand · 08-05-2011, 11:48 PM

hi
what I am trying to say is that spinlocks are disabled on uniprocessor so if I want to use spinlocks in two of my kthreads I will not be ale to .

scenario- global is shared

kthread a //kernel thread
spinlock()//not actual syntax
global++;
spinunlock()//not actual syntax

kthread b //kernel thread
spinlock()//not actual syntax
global++;
spinunlock()//not actual syntax

providing it is uniprocessor now so i cannot use spinlock cause they are disabled .Correct me I am wrong so in such scenararios I am supposed to use other locking schemes.

paulsm4 · 08-06-2011, 01:25 AM

Hi -

Quote:

Correct me I am wrong

OK. You're wrong

1. Sundialsvcs said it best:

Quote:

"Silly rabbit ... what's a spinlock for?" And, if you know that, "what does a spinlock have to guard against if there is only one CPU?"

2.Maybe the source of your confusion is that perhaps you're thinking "if spinlocks are disabled on a UP kernel" (and they are), "then I can't use them in my code." But you CAN!

3. If you have a critical section (for example, in a kernel driver), then use spinlocks.
If this code is executed on a UP, the code will effectively be a no-op.

This article might explain a bit better:

http://www.linuxjournal.com/article/5833

In particular:

Quote:

The basic use of the spinlock is:

Code:

spinlock_t mr_lock = SPIN_LOCK_UNLOCKED;
unsigned long flags;
spin_lock_irqsave(&mr_lock, flags);
/* critical section ... */
spin_unlock_irqrestore(&mr_lock, flags);

The use of spin_lock_irqsave() will disable interrupts locally and provide the spinlock on SMP. This covers both interrupt and SMP concurrency issues. With a call to spin_unlock_irqrestore(), interrupts are restored to the state when the lock was acquired. With a UP kernel, the above code compiles to the same as:

Code:

unsigned long flags;
save_flags(flags);
cli();
/* critical section ... */
restore_flags(flags);

which will provide the needed interrupt concurrency protection without unneeded SMP protection.