On Wed, Sep 15, 2010 at 2:41 AM, Smital Desai <Smital.Desai@xxxxxxxxxxxxxxx> wrote:
________________________________________
From: Venkatram Tummala [venkatram867@xxxxxxxxx]
Sent: Wednesday, September 15, 2010 1:37 PM
To: Smital Desai
Cc: Tayade, Nilesh; Kernel Newbies
Subject: Re: spin locks in uniprocessor system
From: Tayade, Nilesh [Nilesh.Tayade@xxxxxxxxxxxx<mailto:Nilesh.Tayade@xxxxxxxxxxxx>]
On Wed, Sep 15, 2010 at 12:27 AM, Smital Desai <Smital.Desai@xxxxxxxxxxxxxxx<mailto:Smital.Desai@xxxxxxxxxxxxxxx>> wrote:
Thanks and Regards
Smital Desai
________________________________________
Sent: Wednesday, September 15, 2010 12:35 PM
To: Smital Desai; Kernel Newbies
Subject: RE: spin locks in uniprocessor system
> -----Original Message-----
> From: kernelnewbies-bounce@xxxxxxxxxxxx<mailto:kernelnewbies-bounce@xxxxxxxxxxxx> [mailto:kernelnewbies-<mailto:kernelnewbies->Thanks a lot Venkat and Nilesh :)
> bounce@xxxxxxxxxxxx<mailto:bounce@xxxxxxxxxxxx>] On Behalf Of Smital Desai
> Sent: Wednesday, September 15, 2010 11:58 AM
> To: Kernel Newbies
> Subject: spin locks in uniprocessor system
>
> Hi everyone,
>
> It's an extract in LDD3 , regarding spink lock. I have put my query
> in brackets.
>
> Spinlocks are, by their nature, intended for use on multiprocessor
> systems, although a uniprocessor workstation running a preemptive
> kernel behaves like SMP, as far as concurrency is concerned.
> ( I need to understand , how this is true with an example preferably
> )
>>On uniprocessor system even if you have a task scheduled, the interrupt
>>can still come and should be handled by that processor. So let's say you
>>get a timer interrupt - the schedule() will be called on return and if
>>there is any higher priority task waiting, your previous task can get
>>scheduled out.
>>This is referred to as pseudo concurrency (Please refer Robert Love).
ok .. i might sound silly but in this case too.. When the second task tries to acquire
the same spin lock , it will again cause the processor to spin continuously hogging it completely ..
then how does the first task gets a chance to execute and release the spin lock.
The second task will eventually be context switched out. And at some point the process holding the spinlock will get a chance to run & it will release the spinlock eventually. Having said that, whenever the second process executes, it will keep spinning waiting for the spinlock. Thats why, it is not a good idea to use spinlocks in a uniprocessor environment. Think Correctness Vs. Efficiency. Spinlocks are required to ensure CORRECTNESS in a uniprocessor environment with preemption enabled. However, spinlocks are not the most efficient synchronization primitives that should be used in a uniprocessor environment.
On UP, spin_lock is defined as preempt_disable, and spin_unlock is defined as preempt_enable
True.
I was thinking that only interrupt can conetxt switch the spin lock holding process out so my job should be done when i disable interrupts as soon as i hold the lock, but i forgot the fact that in case of preemptive multitasking, the operating system kernel can also initiate a context switch to satisfy the scheduling policy's priority constraint, thus preempting the active task.
Not Quite . Ok, I take back my words from the previous explanation. That is only true is there are multiple processors. Basically your question "When the second task tries to acquire the same spin lock , it will again cause the processor to spin continuously hogging it completely" has a problem. This case will never occur on an uniprocessor because spin_lock(...) will disable preemption. That is, it will increment the variable preempt_count in the thread_info structure. Whenever the scheduler tries to preempt the currently running task, it looks at the preempt_count value of the current executing task. If this value is non-zero, then it cannot preempt the task. So, until you give up the spin lock, you will own the only processor available.
So, the second process doesn't have a chance to execute. When you do spin_unlock(...), it will decrement preempt_count. Hence, when preempt_count reaches 0, the scheduler can preempt the task.
So, the second process doesn't have a chance to execute. When you do spin_unlock(...), it will decrement preempt_count. Hence, when preempt_count reaches 0, the scheduler can preempt the task.
Venkat , can you please elaborate more on determining level of the contention of the lock on UP / MP Systems ?
Note that even in multi-processor environments, spinlocks are used in cases where the level of the contention of the lock is usually low. Because here too, the process wastes CPU cycles by waiting for the spinlock. If the contention is high, the wastage will increase.
Lock Contention is something that depends on a case-by-case basis. Suppose, you just have to increment a variable in the critical section.
spin_lock(...)
var++
spin_unlock(...)
That means that you will be holding the lock for a small amount of time. Spin locks are the correct locks to use in such a case. If you had used a mutex instead, the task would be put to sleep, a new task is selected to run & at some time, the previous task is switched back in. So, that involves two context switches. So, theoretically, you should only use a spinlock if the time spent in the critical section is less than time taken for two context switches because the overhead of 2 context switches is not worth it, in this case. O'wise use a mutex. Since, we cannot measure this time perfectly, we just use our intuition & the task at hand to figure out if a spin lock or a mutex should be used. Minimal amount of time should be spent holding the lock.
spin_lock(...)
var++
spin_unlock(...)
That means that you will be holding the lock for a small amount of time. Spin locks are the correct locks to use in such a case. If you had used a mutex instead, the task would be put to sleep, a new task is selected to run & at some time, the previous task is switched back in. So, that involves two context switches. So, theoretically, you should only use a spinlock if the time spent in the critical section is less than time taken for two context switches because the overhead of 2 context switches is not worth it, in this case. O'wise use a mutex. Since, we cannot measure this time perfectly, we just use our intuition & the task at hand to figure out if a spin lock or a mutex should be used. Minimal amount of time should be spent holding the lock.
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx<mailto:ecartis@xxxxxxxxxxxx>
Regards,
Venkatram Tummala
>
> If a nonpreemptive uniprocessor system ever went into a spin on a
> lock, it would spin forever; no other thread would ever be able to
> obtain the CPU to release the lock. For this reason, spinlock
> operations on uniprocessor systems without pre-emption enabled are
> optimized to do nothing, with the exception of the ones that change
> the IRQ masking status.
> ( I don't get the meaning of last sentence "with the exception of
> ......" Please can somebody explain )
>
>>I am not sure about this statement, though. Would appreciate if someone
>>can provide some pointers.
>
> Thanks and Regards
> Smital Desai
>
--
Thanks,
Nilesh
______________________________________________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--
To unsubscribe from this list: send an email with
______________________________________________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
