>> Hi, >> In Process cotext you can hold spin_lock and also you can up().. And >its >> better to use spin_lock_irqsave intead of spin_lock in process context.. >> > >spin_lock_irqsave is superset of all locks and can be used always, but >its better to use __semphores__ in process context as you don't need >to keep spinning to acquire lock rather can go to sleep ! > >Can consult "nreliable Guide To Locking" by Rusty Russell >(http://www.kernel.org/pub/linux/kernel/people/rusty/kernel- >locking/index.html) > >> >> On 2/8/06, Hareesh Nagarajan <hareesh.nagarajan@xxxxxxxxx> wrote: >> > >> > In process context (and interrupt context, while we are at it) can we >> > hold a spin lock and call up() (on a semaphore)? Apart from the usual >> > issues pertaining with deadlocks - are we guaranteed that an up is a >> > non-blocking operation? >> > > >AFAIK, up can be called while holding spin_lock as up wake_ups the >process which is/was waiting on the queue due to call of down and is >non-blocking operation ! (CMIIW) When we hold a semaphore, it means that we have indirectly/directly called schedule() call. This permits us to sleep. At a point of time, when we finally want to wakeup and issue up(), the kernel sub-system will take care of intimating the all the processes sleeping on the semaphore regarding wake-up call. I presume it will be like a forking of another process within the kernel. Regards, Mukund Jampala -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
