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/
