RE: About kernel preemption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The reason for this is that we can not afford to waist CPU cycle for a
full time slice of a process. So in case T1 acquired the spinlock and
then prempted, now whenever T2 will be resuduled before T1 again
reschedules, processor cycles will be waisted for whole time slice, in
that cases T2 will just spin on the lock for the whole of its time
slice, waiting for the lock to be released (this is the case of uni
processor). In SMP the the situation might not be this much critical, as
T1 can be rescheduled on processor 2 at the same time when T2 is getting
executed at processor 1.

I think Robert said right that critical section should not be prempted
if we have acquired a spinlock, but it can be premptem if it has
acquired a semaphore, as semaphore is a sleeping lock and does not put
the other processes on spining, waiting for that lock to be released,
rather those waiting processes are put to sleep on waitqueues.


Regards,
Gaurav

-----Original Message-----
From: kernelnewbies-bounce@xxxxxxxxxxxx
[mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Robert Love
Sent: Friday, September 10, 2004 9:06 AM
To: martim@xxxxxxxxxxxxxxxxx
Cc: kernelnewbies@xxxxxxxxxxxx
Subject: Re: About kernel preemption

On Fri, 2004-09-10 at 00:00 -0300, Martim Carbone wrote:

> Is it really a deadlock? Let's assume the following scenario:
> 
> - Thread 1 acquires lock A (spinlock) and gets preempted
> - Thread 2 tries to acquire lock A and spins
> - At some point in the future, the system timer interrupts thread 2,
> determines that its timeslice has finished and sets need_resched. Some
> other process it scheduled
> - After X reschedules, thread 1 is once again scheduled and releases
lock A.
> - After Y reschedules, thread 2 is once again scheduled and, this
> time, lock A is free, so it acquires the lock and executes the
> critical region.

Are you serious?

I suppose in this example, assuming that T2 is always suspended and that
T1 is always rescheduled, you do not have a deadlock, but an indefinite
postponement, although this is not much more acceptable than a straight
up deadlock.

	Robert Love



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/



--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux