tests/isr_thread_yield_higher: test behavior from interrupt#11759
tests/isr_thread_yield_higher: test behavior from interrupt#11759cladmi wants to merge 2 commits intoRIOT-OS:masterfrom
Conversation
|
Not sure who to ask more about this issue… |
Run scheduler after interrupts have finished. The equivalent of |
So the test is indeed showing the right behavior, and If we do not mind loosing the debug messages, this should also be updated to directly use Lines 186 to 209 in c9bf22b |
Hmm. Let's think this through. It is obviously a common pattern to check if in isr, maybe yield, maybe set "sched_yield_higher". But the isr check is not necessary in all cases. And we should avoid wasting cycles at this level, or at least establish if always checking for isr_is_in() has a measurable impact on context switches. |
It is currently checked everytime for RIOT/cpu/atmega_common/thread_arch.c Lines 238 to 249 in 50ea0d8 Lines 212 to 258 in 50ea0d8 RIOT/cpu/esp8266/thread_arch.c Lines 206 to 240 in 50ea0d8 |
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
|
Lines 209 to 229 in ecdccdd |
|
Reference as it was how it was found, |
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
|
@MrKevinWeiss This is still there, show we do something about it for the release. |
|
Something tells me the fix won't be ready that fast. The challenge of doing a summer release is many people are not available. As a worst case I will put it in the release notes. |
|
I noticed that also |
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
because of pr RIOT-OS#11759: not all boards check for is_in_irq when thread_yield_higher
9f96449 to
e1be672
Compare
|
IMO we should also just implement static inline void thread_yield_higher(void)
{
if (irq_is_in()) {
sched_context_switch_request = 1;
}
else {
thread_yield_higher_arch();
}
}And |
|
LGTM. Feel free to squash! |
3b8169a to
f3bd3ed
Compare
f3bd3ed to
b23c3c8
Compare
From interrupt context on some architectures, thread_yield_higher yields immediately, on some others it yields after the end of the interrupt. However, some cpus implementation like 'atmega_common' have an explicit 'irq_is_in' switch to do a different handling. So I assume either this special handling is not required, or the architectures that behave differently are wrong.
b23c3c8 to
9f5822c
Compare
|
Another Travis comment popped up, amended and pushed right away. (Only changed the type for |
maribu
left a comment
There was a problem hiding this comment.
Sorry for the late comments. Feel free to squash right in.
|
@maribu I also noticed that this PR was before |
| include ../Makefile.tests_common | ||
|
|
||
| USEMODULE += xtimer | ||
| USEMODULE += stdin |
There was a problem hiding this comment.
I'm referring the stdin module. (Sorry for the confusion.)
|
Is this one still relevant @maribu? |
|
I think this should get in. It will need a rebase to be passing the CI, though. |
kfessel
left a comment
There was a problem hiding this comment.
nice test for the expected behavior
needs rebase and optional ztimer
Contribution description
From interrupt context on some architectures, thread_yield_higher yields
immediately, on some others it yields after the end of the interrupt.
However, some cpus implementation like 'atmega_common' have an explicit
'irq_is_in' switch to a different handling.
So I assume either this special handling is not required, or the
architectures that behave differently are wrong.
Question
How should
thread_yield_higherbehave from interrupt context ?Note that masking interrupts also let it currently
yield, at least on themsba2.The problem was found as
xtimer_mutex_lock_timeoutis usingthread_yield_higherfrom interrupts #6158 (when not spinning).It currently brings back to the main thread with
xtimer,_in_handlervariable still set to 1, so_timer_callbacknot being finished.Testing procedure
Run the test on different cpus/boards.
Boards that have a value of
1, so yield after the interruptBoards that have a value of
0, so yield inside the interruptmsba2cpu/arm7_common: Fix thread_yield_higher in ISR #11887FIXED value on `msba2`
#11887
Test run on most of the boards, it fails for the
msba2.https://ci-ilab.imp.fu-berlin.de/job/experimental-pull-request-tests/40/consoleText
Issues/PRs references
This different behavior was found when testing #11660
The original implementation was using
thread_yield_higheralready, but not setting a value after.