Dear Stuart,
> > > a *hardware* priority, this is unrelated to the concept of the priority
> > > of threads. Usually, when an interrupt occurs, it interrrupts whatever
> > > is running provided that a) interrupts are enabled, b) if currently in
> > > an ISR, the hardware priority of the new interrupt is higher than the
> > > current interrupt priority (implementation is architecture dependant).
> >
> > This is your wish or the reality? ;-)
>
> I think there is a miscommunication here. If you mean the 'current' as
> in Linux terms (e.g current->pid) then yes of course that may refer to a
> low priory (Linux) task/process.
No. 'current' means the actual version of RT-Linux (2.x).
> difference in context between a true interrupt handler, and that which
> it interrupts (provided it is not already in an ISR).
I speak about RT-Linux hard interrupt handlers.
> > We were speaking so far, that ISRs run long because threads awaken
> > by them grabs the CPU.
>
> I think I understand ? What was being said is that if you are in an
> hard interrupt handler, and you use pthread_wakeup_np (or similar in
> RTAI) to call the scheduler, the new RT thread runs before you exit the
> ISR.
Yes, this is the situation.
> Victor was saying that depending an what you call, you can change the
> behavior to let the ISR finish and then have the RT task/thread run
> (pthread_mutex_unlock), this may be what you need.
I use a "library function" that calls pthread_wakeup_np().
I do not want to rewrite everything.
> > Now I have such an ISR. There can be occur such a situation,
> > that it runs in two instances because the first one is delayed
> > by a high priority thread, meanwhile the hardware IRQ is delivered
> > again.
>
> You need to make sure that the thread is outside ISR context (I think
All of my threads are interrupt driven.
> ?). Fundamentally you need to make sure that you have time to complete
> the thread work before the next re-run request occurs (is that correct
> ?, I'm guessing you want to avoid reentrancy)
There is no time for it.
However reentrancy is not a problem.
I just dislike the concept.
Sorry if I was confusing.
I wrote my mail not for asking help to solve a given problem
but I suggested a possible improvement of RTLinux IRQ handling scheme.
Is this forum is not adequate for discussing principal issues? ;-)
(My program works well since I realized what happens.)
Regards
Gabor
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
