Hi there, Testing my hal for Cortex-R4, I'm getting a funny behaviour for test kernel/.../thread2. It seems that when two threads have the same priority, there is no timeslicing working (interestingly, the timeslice tests also get deadlocked). The problem seems to appear because thread#2 preempts thread #1, (thread #1 seems to do more API calls than thread #2, but reducing the unnecessary ones does not solve the problem), so thread #2 gets waiting for thread #1 to increase "q", and thread #1 never gets scheduled to realize that "q" has moved to 101, so it can move it to 102... I've added lots of traces (see attached modified thread2.cxx, and the trace output below). Is this test expected to succeed without timeslicing? Is it possible that the checks that thread#1 does at that critical point might tip off the things to the wrong side? Or is it that I might have some wrong configuration option set or unset? If none of the above... Any idea on what could be wrong? Regards. These are the extra output that tries to show what is wrong: INFO:
INFO:
INFO:
INFO: INFO: 1.> INFO: INFO: 2.> INFO: INFO: 3.> INFO: INFO: INFO: 4.> INFO: INFO: 5.> INFO: INFO: INFO: 6.> INFO: INFO: INFO: 7.> INFO: INFO: 8.> INFO: INFO: 9.> INFO: INFO: INFO: 10.> INFO: INFO: 11.> INFO: INFO: 12.> INFO: INFO: 13.> INFO: 100.> INFO: INFO: 101.> INFO: