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
> --
> programing a layer 3+4 network protocol for mesh networks
> see http://michaelblizek.twilightparadox.com
>
>
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.


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?

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. I want my
module to be
as reentrant as possible without making user do too many things.


-Leo.

Reply via email to