On Fri, 2006-02-10 at 16:56 +0500, Fawad Lateef wrote: > 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() Let's consider the following example: We have a network device ,and processes call recv() to take data from the network. e don't want to waste cpu time until data have arrived for us, so we have a semaphore,or better a wait queue, and sleep on it waiting... It this case, interrupt handler of the network interface, must notify the sleeping process that data have arrived, so a way to do this it to place somewhere the data and then wake up the sleeping proc. Of course this can implemented and with other ways, but still it's just an example. > 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 > :) If we see what exactly up/wake_up in general case, we'll see that at the end wake_up_common is called, and this call is protected by a spinlock (with irqsave functions). wake_up_common just scan the wait list, and trying to wake processes, so it cannot (and mustn't) be a blocking call. Stavros Passas -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
