On 2/10/06, Mukund JB. <mukundjb@xxxxxxxxxxxxxxxxxxxxx> wrote: > > >> 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. Could not get, what you mean by above statment. In waking up the waiting processes, there is no forking of new process. Forking is totally a different concept, it is to give birth to new process. When we call up(), this function, wakes up all the processes sleeping on semaphore by changing there state from TASK_INTERRUPTIBLE / TASK_UNINTERRUPTABLE to TASK_RUNNING. up() function is not responsible for pulling out these processes from waiting queue of semaphore, its the responsiblity of each process to pull itself out of waiting queue maintined on semaphore. When the waked up process gets the chance to run on CPU (basically schedules on CPU), at that time first thing it do is to pull out of waiting queue of semaphore. I think, up() can be called from interrupt context as it does not put the process to sleep, but basically the coe which holds the semaphore by calling down() is responsible for calling up() also and as interrupt context can not use down() call, so indirectly it can not use up() call also. I am not able to think of a situation, where the process context calls the down() and interrupt context calls the up(). regards, -Gaurav regards, -Guarav > > Regards, > Mukund Jampala > > > > > > > -- > 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/
