Re: About kernel preemption

[Martim Carbone <mcarbone@xxxxxxxxx>]

Robert,

> The reason is because you can deadlock (acquire lock A, preempt, new
> thread acquires lock A).

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.

Of course, there are more complex scenarios, and it can take some time
for lock A to be released by thread 1, but isn't it possible to say
that, with the help from the system timer, the lock will always be
freed at some point?

Thanks again,

-- Martim

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