________________________________________ From: Venkatram Tummala [venkatram867@xxxxxxxxx] Sent: Wednesday, September 15, 2010 1:51 PM To: Tayade, Nilesh Cc: Smital Desai; Kernel Newbies Subject: Re: spin locks in uniprocessor system On Wed, Sep 15, 2010 at 12:51 AM, Tayade, Nilesh <Nilesh.Tayade@xxxxxxxxxxxx<mailto:Nilesh.Tayade@xxxxxxxxxxxx>> wrote: > -----Original Message----- > From: Smital Desai [mailto:Smital.Desai@xxxxxxxxxxxxxxx<mailto:Smital.Desai@xxxxxxxxxxxxxxx>] > Sent: Wednesday, September 15, 2010 12:58 PM > To: Tayade, Nilesh; Kernel Newbies > Subject: RE: spin locks in uniprocessor system > > > > >>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. > CMIIW, pertaining to the uniprocessor system, the first task will get a chance only when it has priority greater than any other tasks. To avoid such things, maybe we can go for non-blocking operations before acquiring spinlock. int spin_trylock(spinlock_t *lock); int spin_trylock_bh(spinlock_t *lock); True, but the priority of process spinning in the CPU waiting for the spinlock will be decreased as time progresses because it is using lots of CPU cycles. And as time progresses, the priority of the process holding the spinlock will increase & it will get a chance to run. Think about this, you cannot get a high prority process spinning in an infinite while loop in a uniprocessor system to lock up the whole system. Sure, response times will decrease but eventually all processes should be able to run even then. We can't have a scheduling policy which overlooks the problem of starvation in any case. But, in an uniprocessor environment, if you want to use spinlocks, spin_trylock is a good way to go as Nilesh said. Spin_trylock will be good in scenarios where the process can go & do something else if spin_trylock fails. Obviously, this is not possible in all cases. There will be scenarios where you absolutely must have a lock to continue further. In those cases, spin_trylock will not help as you have to keep calling spin_trylock which is equivalent to calling spin_lock(...) in terms of performance benefits. So, you have to take the following factors in consideration while deciding your locking mechanisms : Contention Level (Performance) & Correctness Again Thanks a lot for explaining :) I have understood your point , but not really able to think of scenarios about when spin_trylock () will not suffice and we have to be spinning. If you can explain that with some scenario , it will be more clear to make disctinction about spin_trylock ( ) and spin_lock ( ) Regards, Venkatram Tummala -- Thanks, Nilesh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx<mailto:ecartis@xxxxxxxxxxxx> 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. ______________________________________________________________________ -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
