Messages in this thread | | | Date | Sat, 23 Jun 2007 22:32:55 +0530 | From | "Satyam Sharma" <> | Subject | Re: "upping" a semaphore from interrupt context? |
| |
On 6/23/07, Oliver Neukum <oliver@neukum.org> wrote: > Am Samstag, 23. Juni 2007 schrieb Satyam Sharma: > > * 3. set up a timer and schedule another function to service the > > * interrupt / do what needs to be done then, hopefully the mutex > > * would be uncontended then => *gargh* > > You could use schedule_work(). However then why not use it always. > This would make sense if what you want to do is outright trivial.
If you use schedule_work() to pass off work from interrupt context to process context, then you wouldn't be calling down_trylock() from interrupt context in the first place (which is what is being discussed here). You would simply pass off the entire code that uses the shared data (and wraps a *proper* down() or mutex_lock() around it, not the _trylock() variant) to the workqueue.
Also, that is precisely my point too. What I'm saying is that it is generally poor design to be wanting to use the _trylock() variant of semaphore / mutex in interrupt context. Workqueues _are_ the preferred mechanism to use for (most) such cases where you need to do something that may require you to sleep.
Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |