-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ticker test improvement #6935
ticker test improvement #6935
Conversation
/morph build |
How does that fit the ticker feature branch? It's going to be merged soon so if it's not applicable to the new branch should we skip it to avoid conflicts? |
Build : SUCCESSBuild number : 2052 Triggering tests/morph test |
Test : FAILUREBuild number : 1862 |
Exporter Build : SUCCESSBuild number : 1695 |
@maciejbocianski Could you answer @bulislaw's question? |
/morph test |
Test : SUCCESSBuild number : 1867 |
@bulislaw it's not critical, could be postponed. |
Setting this as needs preceding PR. |
@bulislaw Since HAL has landed, I take it this is clear to continue? |
42dea31
to
7a0a01c
Compare
7a0a01c
to
45d295d
Compare
@@ -91,9 +95,12 @@ void test_multi_ticker(void) | |||
} | |||
|
|||
Thread::wait(MULTI_TICKER_TIME_MS + TICKER_COUNT + extra_wait); | |||
multi_counter_snapshot = multi_counter; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When very early interrupt is scheduled (e.g now + 2[ticks]) then it's likely that it won't be fired in some circumstances and as a result there is overdue event in queue. That overdue event can be mistakenly scheduled again by Ticker::detach (detach calls schedule if head was removed). That's why we should check interrupts counter immediately after wait period and before detach loop
I don't follow the description and these changes here. can you elaborate how multicounter snapshot fixes it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume the following scenario (time is mesured in ticks)
Running test_multi_ticker with TICKER_COUNT == 3
(tickers t1, t2, t3) and ticker period 100
Then we get following events scheduled at time 0
event_queue: e1(100), e2(105), e3(105)
now == 0
at time 100 e1 is triggered (and next event for t1 is scheduled e11(200))
at time 103 e2 interrupt is set(scheduled) (now == 103)
for e2 interrupt will not be trigerred (trying to set (now + 2) what is less then (now + 3))
(on some targets to be sure that interrupt will be triggered we can't set interrupt earlier than (now + 3 ticks))
After wait instruction we have following state:
event_queue: e2(105), e3(105), e11(200)
multi_counter == 1
(e1 triggered)
now == 110
multi_counter_snapshot = multi_counter
In detach loop:
detach t1 events then e11 will be removed
detach t2 events then e2 will be removed
at this point since head was removed,
schedule_interrupt
is called and since e3
is overdue fire_interrupt
is called for e3
(and next event for t3 is scheduled e31(205))
detach t3 events then e31(205) will be removed
After detach loop we have following state:
event_queue: empty
multi_counter == 2
(e1 and e3 triggered)
now == 115
result when checking multi_counter
: expected 3 is 2
result when checking multi_counter_snapshot
: expected 3 is 1
So using multi_counter_snapshot
we catch real test status, just after test end
for (int i = 0; i < TICKER_COUNT; i++) { | ||
ticker[i].detach(); | ||
} | ||
TEST_ASSERT_EQUAL(TICKER_COUNT, multi_counter_snapshot); | ||
TEST_ASSERT_EQUAL(TICKER_COUNT, multi_counter); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if multi_counter_snapshot
catches real test status, why we still check multi_counter
against TICKER_COUNT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because detach
calls schedule_interrupt
in some circumstances (e.g. when head event is removed), so it's good to check if no more callbacks is raised during detaching.
BTW, now I see that the first ASSERT
can be moved up, where the snapshot is taken
And will add some comment to second check
/morph build |
Build : SUCCESSBuild number : 2282 Triggering tests/morph test |
Make multiticker test more reliable when scheduling very early interrupts. When very early interrupt is scheduled (e.g now + 2[ticks]) then it's likely that it won't be fired in some circumstances and as a result there is overdue event in queue. That overdue event can be mistakenly scheduled again by `Ticker::detach` (detach calls schedule if head was removed). That's why we should check interrupts counter immediately after wait period and before detach loop
45d295d
to
27bf6cf
Compare
Pausing CI until 5.9 RC3 completes CI. Will restart jobs when able. |
Exporter Build : SUCCESSBuild number : 1904 |
/morph build |
Build : SUCCESSBuild number : 2330 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 1952 |
Test : SUCCESSBuild number : 2110 |
Description
Make multiticker test more reliable when scheduling very early interrupts.
When very early interrupt is scheduled (e.g now + 2[ticks]) then it's likely that it won't be fired in some circumstances and as a result there is overdue event in queue. That overdue event can be mistakenly scheduled again by
Ticker::detach
(detach calls schedule if head was removed). That's why we should check interrupts counter immediately after wait period and before detach loopPull request type