On Wed, Sep 15, 2010 at 2:50 AM, Smital Desai <Smital.Desai@xxxxxxxxxxxxxxx> wrote:
________________________________________
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-----
Again Thanks a lot for explaining :)> 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
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.
Venkatram Tummala
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.
Venkatram Tummala
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx<mailto:ecartis@xxxxxxxxxxxx>
Regards,
Venkatram Tummala
--
Thanks,
Nilesh
--
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.
______________________________________________________________________
