Possible bug in RTEMS core.

[osv at Javad.RU (Sergei Organov)]

Hello;

I think there is a bug in the '_Thread_Yield_processor()' routine. I
had encountered problem (the program just hangs) that disappears if I
comment out '_ISR_Flash(level)' call in the middle of the routine. The
problem description follows. It'd be fine if somebody experienced in
RTEMS internals takes a close look into '_Thread_Yield_processor()'.

The problem occurs when there are two tasks with equal priorities that
are just usual forever loops calling
rtems_task_wake_after(RTEMS_YIELD_PROCESSOR) at every loop
iteration. To run into trouble it's enough to have one of these two
tasks to wait on, let's say semaphore, that is released by _interrupt
service routine_ that handles asynchronous interrupt. In my program
the semaphore is inside RS232 driver and task just calls 'printf' that
eventually results in waiting on the semaphore:

task1() {
  for(;;) {
    printf("Task1\n");
    rtems_task_wake_after(RTEMS_YIELD_PROCESSOR);
  }
}

task2() {
  for(;;) {
    rtems_task_wake_after(RTEMS_YIELD_PROCESSOR);
  }
}

Commenting out any of calls makes problem go away. Making priorities
for 'task1' and 'task2' different (not the same) makes problem go
away. Commenting out '_ISR_Flash(level)' inside
'_Thread_Yield_processor' makes problem go away.

I used RTEMS 3.6.0 and my own BSP for custom hardware when problem
occured. Unfortunately I have no possibility to check if problem
exists if some of BSPs provided with RTEMS is used. All tests provided
with RTEMS run smoothly with my configuration, though. I looked into
RTEMS 4.0 code - it seems nothing significant was changed in this area
since 3.6.

BTW, do you think it is really critical for maximum interrupt latency
to have _ISR_Flash(level) call in the '_Thread_Yield_processor()'?

Also, I'd like to say that all these isn't at all critical for me - I
just want to inform you that maybe there is some bug here.

Regards,
Sergei Organov.