Hi, After seeing your code snippet, I think you are doing wrong by keeping the spinlock locked and going to sleep. The better idea would be to release spinlock before going to sleep. As Rubini has mentioned clearly in Chapter 5 that we should avoid situations where our code is going to sleep after holding any locking identifier (Semaphore or spinlocks etc), this can lead to a deadlock like situation, if the code which generates an event that will wake up our code is also going to hold the same spinlock. As your code has locked up the spinlock and has gone to sleep so the code which is responsible for waking up your code after getting the spinlock will fails, as it will never be able to get the spinlock, as spinlock is held by sleeping code. So to improve your code, release the spinlock before calling sleep_on() function. As far as the difference between 'sleep_on' and 'interruptible_sleep_on' is concerned, see the following: If your code is using sleep_on, the process will be waked up only if the event occurs for which the sleeping code is waiting. In this somebody should explicitly wake up our code (in device driver, it's normally the interrupt handlers). So if we use sleep_on our code will not be waked up till the time somebody explicitly wakes up the wait queue on which we are waiting. On other hand if we are using interruptible_sleep_on, our code can be waked up in either of the following two situations - if somebody wakes up explicitly the waiting queue on which we are waiting (same as sleep_on). - if the process on behalf of which we have gone to sleep (or in other word, process we have put to sleep) receives any signal (hence the name interruptible_sleep_on). Now regarding spinlocks and semaphores, spinlocks should only be used when the critical region is too short (normally it's used in interrupt handlers), in all other situations we should use other locking mechanisms like semaphore. Hope I did not made it more confusing for you. Regards, Gaurav -----Original Message----- From: kernelnewbies-bounce@xxxxxxxxxxxx [mailto:kernelnewbies-bounce@xxxxxxxxxxxx] On Behalf Of Heap Ho Tan Sent: Sunday, July 25, 2004 9:32 AM To: kernelnewbies@xxxxxxxxxxxx Subject: sleep_on problems Hi, I have the following piece of code, interestingly any line of code after sleep_on will not get executed. Also what is the difference between interruptible_sleep_on and sleep_on, when do you use one versus other? Also for the different types of spin_lock, when do you decide you need one over the other? Thanks Heap-Ho Note in this case if sleep_on suspends the current process, there will be a deadlock situation, is there anyway out of this?? asmlinkage int myeventwait(int eventID) { struct list_head *tmp; struct eventDest *eventtmp; list_for_each(tmp, &event_head){ eventtmp = list_entry(tmp, struct eventDest, event_list); spin_lock_irq(&eventtmp->eventLock); if(eventtmp->eventID == eventID){ //printk("In eventwait and evenID: %d\n", eventtmp->eventID); eventtmp->nb_process=eventtmp->nb_process+1; //printk("No of processes waiting: %d\n", eventtmp->nb_process); sleep_on(&(eventtmp->queue)); spin_unlock_irq(&eventtmp->eventLock); return 1; } spin_unlock_irq(&eventtmp->eventLock); } return -1; } -- 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/
