RE: Can we hold a spin lock and call up() (on a semaphore)

["Mukund JB." <mukundjb@xxxxxxxxxxxxxxxxxxxxx>]

>> 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/