On Thu, Sep 17, 2009 at 11:22 PM, Michael Blizek < [email protected]> wrote:
> Hi! > > On 11:08 Fri 18 Sep , Leonidas . wrote: > > On Thu, Sep 17, 2009 at 9:43 PM, Michael Blizek < > > [email protected]> 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 > > 1. My profiling functions might do following in worst case { Part 1 spinlock populate a tree & search a tree & delete a node from tree spinunlock Part 2 Lock Update an error buffer Unlock } Which might be quite an overhead for an ISR. 2. in_interrupt would do for me. 3. My module would be single threaded, unless I strictly required. The whole issue is to lock the update error buffer i.e. part 2 above. This buffer updated from part 2 would be read in read method of module. -Leo.
