________________________________________ From: Venkatram Tummala [venkatram867@xxxxxxxxx] Sent: Wednesday, September 15, 2010 4:41 PM To: Smital Desai Cc: Tayade, Nilesh; Kernel Newbies Subject: Re: spin locks in uniprocessor system On Wed, Sep 15, 2010 at 2:50 AM, Smital Desai <Smital.Desai@xxxxxxxxxxxxxxx<mailto:Smital.Desai@xxxxxxxxxxxxxxx>> wrote: ________________________________________ From: Venkatram Tummala [venkatram867@xxxxxxxxx<mailto: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><mailto:Nilesh.Tayade@xxxxxxxxxxxx<mailto:Nilesh.Tayade@xxxxxxxxxxxx>>> wrote: > -----Original Message----- > From: Smital Desai [mailto:Smital.Desai@xxxxxxxxxxxxxxx<mailto:Smital.Desai@xxxxxxxxxxxxxxx><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 ( ). Lets take an example. Suppose you are writing a system call packet_receive(...) which receives the network packets and updates statistics. ( I am just making up examples here. There is no such system call in reality.). Suppose the statistics are stored in a shared object. So, you will receive the packet, you will do a spin_trylock(&statistics). If it succeded you update the statistics & release the spin lock. If it failed, you still continue to receive the packets. spin_trylock is useful instead of spin_lock here because updating statistics is not that important here. You can update them later if can't acquire the lock right away. But it is important to receive the packets. If somebody else already owns the statistics spin lock, it doesn't make sense to wait for them to release the lock so that we can update the statistics and delay the actual important task of receiving the packets. On the other hand, suppose you want to update the page table entries, you absolutely MUST acquire the lock, there is no escaping from it. You can only continue the page table update if you have the lock. So, spin_trylock doesn't help here. Hope this example clears the point. Yeh , pretty good explanation . This explanation will always help many of us while making a decision on selecting appropriate spin_(un)lock () variant based on the situation. Thanks, Smital Desai Venkatram Tummala Regards, Venkatram Tummala -- Thanks, Nilesh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx<mailto:ecartis@xxxxxxxxxxxx><mailto: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. ______________________________________________________________________ ______________________________________________________________________ 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
