Hi! On 11:08 Fri 18 Sep , Leonidas . wrote: > On Thu, Sep 17, 2009 at 9:43 PM, Michael Blizek < > michi1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Hi! > > > > On 17:20 Thu 17 Sep , Leonidas . wrote: > > > Hi List, > > > > > > I am aware of the fact that in interrupt context one should not use > > > mutexes/semaphore > > > and should stick to spinlocks. > > > > Yes, exactly. > > > > > I am developing a module which exposes interfaces which could be called > > from > > > any/all > > > contexts. And I manipulate complex data structures in my functions. Being > > on > > > safer side > > > I should stick to spinlocks. But in most of the cases it would not be > > > needed, meaning my > > > functions would get called mostly from process contexts, so spinlocks > > sounds > > > wasteful > > > since my critical sections are long and painful. > > > > Is there any way to view your code? > > > > 1) Executing long functions in interrupt context is bad, because this > > introduces latencies into the system. Try to put at least the big functions > > into a workqueue. > > > > 2) You can try to remove the locking outside of this module and make it the > > responsibility of the module user. ... > Michi, > > Actually, I have not written any code yet, just pondering over design as of > now. > Would start writing only once some of these rough edges are sorted out. > > Yes, I should ideally move out the big functions outside ISRs, but issue > with my > module is, I would not know from where I am getting called. My module will > just > export apis which modules can call from whereever they want, and I cant put > it > as a constraint that they should not call from ISRs, my module is going to > be bit > like profiling module so a user might actually want to call it from ISR to > profile it. Are you sure the functions will be that long and painful? When profiling this may easily distord the data you get. What routines are you afraid of? > Can I do following? > As soon as I enter my functions, I check whether I am running in interupt > context > or process context and spwan a tasklet/workqueue if I am in interrupt > context or proceed in the > same function if I am in process context. This would make more sense right? You should be able to check whether you are running in interrupt context with in_interrupt. I do not know whether it also checks if you will be running in non interrupt context with interrupts disabled due to spinlocks or so, but I think it does. Spawning a workqueue task is always possible, no matter whether you interrupts are disabled or not. > But above point does not solve the locking issue? Does it? And I can't move > locking outside > my module and ask user to do so since that might not be possible. This may be the case if locking is fine grained or if you have your own threads or so which have to do locking for themselves. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
