On 2/10/06, Gaurav Dhiman <gauravd.chd@xxxxxxxxx> wrote: > On 2/10/06, Mukund JB. <mukundjb@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > 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. > <snip> > > 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(). > Ya, me too agree with you Gaurav about not able to get the situation in which process calls down and interrupt handler calls up(), but the question asked by the thread creator is: Is up is a blocking or non-blocking operation because he wants to call up() while holding the spin_lock (in which sleeping is not allowed) ? and according to my knowledge and as you said too that up() won't sleep, so it can be done :) -- Fawad Lateef -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
