Re: Locking and interrupt handlers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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
--
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.




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux