On Wed, Sep 15, 2010 at 3:58 AM, Venkatram Tummala <[email protected]>wrote:
> On Wed, Sep 15, 2010 at 2:41 AM, Smital Desai < > [email protected]> wrote: > >> ________________________________________ >> From: Venkatram Tummala [[email protected]] >> Sent: Wednesday, September 15, 2010 1:37 PM >> To: Smital Desai >> Cc: Tayade, Nilesh; Kernel Newbies >> Subject: Re: spin locks in uniprocessor system >> >> On Wed, Sep 15, 2010 at 12:27 AM, Smital Desai < >> [email protected]<mailto:[email protected]>> wrote: >> >> Thanks and Regards >> Smital Desai >> ________________________________________ >> From: Tayade, Nilesh [[email protected]<mailto: >> [email protected]>] >> Sent: Wednesday, September 15, 2010 12:35 PM >> To: Smital Desai; Kernel Newbies >> Subject: RE: spin locks in uniprocessor system >> >> > -----Original Message----- >> > From: [email protected]<mailto: >> [email protected]> [mailto:kernelnewbies-<mailto: >> kernelnewbies-> >> > [email protected]<mailto:[email protected]>] 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. >> >> Thanks a lot Venkat and Nilesh :) >> >> 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. > To Summarize, spinlocks are implemented in the following ways : UP with Preemption disabled -> spin_lock & spin_unlock is a no-op. UP with Preemption enabled -> spin_lock will disable kernel preemption, unlock will enable it. But the actually locking code is not present. SMP -> spin_lock will disable kernel preemption on that processor & implement the actual locking code to ensure that shared data is not accessed from other CPUs . spin_unlock will do the opposite. Regards, Venkatram Tummala > >> 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. >> >> Venkat , can you please elaborate more on determining level of the >> contention of the lock on UP / MP Systems ? >> > > 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. > > > >> 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 >> "unsubscribe kernelnewbies" to [email protected]<mailto: >> [email protected]> >> Please read the FAQ at http://kernelnewbies.org/FAQ >> >> >> >> ______________________________________________________________________ >> >> 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. >> >> ______________________________________________________________________ >> > >
