Interrupt handlers and RTEMS Queues (Breaking the Rules)

[John Bebbington]

Hello,

A quick question about the effect of not following the restrictions given in
the RTEMS users manual regarding Interrupt Service Routines (ISRs) using
RTEMS queues and NOT returning through the RTEMS scheduler on RTE.

Given the following scenario:
=============================
There are 2 ISRs (i.e. level 5 and level 6 hardware priority) that write
data asychn. to the same RTEMS Queue but these ISRs were not configured in
the vector table by using the RTEMS directive "rtems_interrupt_catch".
In addition there is a task waiting to read from the same Queue but blocked
when the queue is empty.


Question:
=========
1) Is the writing to the RTEMS queue still protected so that the level 6 ISR
may interrupt the level 5 ISR while the level 5 was  performing a write to
the RTEMS Queue? i.e. is the queues integrity still protected regardless of
not using the RTEMS directive "rtems_interrupt_catch"?

2) Would the waiting task (providing it was the highest priority task in the
system) get "readied and start" on the next occurance of the RTEMS system
tick? For example if the tick was 3.125 ms and the ISR 5 wrote 3 messages in
the queue since the last tick, would the next tick handler recognise there
are entries in the queue and therefore ready the waiting task?


Rational:
=========
The reason for the 2 questions is that due to performance a high interrupt
frequency we would like to try to optimize the amount of cpu time used in
"house keeping" by not having to always go through the RTEMS scheduler on
RTE. At the same time we want to be able to use rtems queues, even at the
cost of having a "reading" at only the system tick frequency.

Any comments would be gratefully received.

John Bebbington.