On Wed, Sep 15, 2010 at 12:51 AM, Tayade, Nilesh <Nilesh.Tayade@xxxxxxxxxxxx> wrote:
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
Regards,
Venkatram Tummala
> -----Original Message-----
> From: Smital Desai [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, theCMIIW, pertaining to the uniprocessor system, the first task will get a
> 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.
>
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
Regards,
Venkatram Tummala
--
Thanks,
Nilesh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
