I found a strange thing.
I have a hardware IRQ handler that wakes up a sleeping task:
it_handler(.....)
{
...
rtl_printf("checkpoint 1\n");
if (waiting_thread) pthread_wakeup_np(waiting_thread);
rtl_printf("checkpoint 2\n");
...
}
user_thread(...)
{
...
rtl_no_interrupts(flags);
waiting_thread = pthread_self();
pthread_make_periodic_np(waiting_thread, sometime, 0);
pthread_wait_np();
rtl_printf("checkpoint 3\n");
waiting_thread = NULL;
rtl_restore_interrupts(flags);
...
}
Diagnostic printf-s show that the executing order is 1-3-2.
This means, that priority of interrupt handler thread is not
definitely higher than priority of the normal thread.
When pthread_wakeup_np() reschedules threads, user_thread
gets the control instead of it_handler.
I could accept this if priority of an IRQ handler would be _well-known_
or could be set.
But in lack of documentation one may think that it has
the highest possible priority and no user created threads can beat it.
What is the matter?
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/
