Skip to content
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

Merged
merged 1 commit into from
Jun 13, 2018
Merged

Conversation

maciejbocianski
Copy link
Contributor

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 loop

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

@maciejbocianski
Copy link
Contributor Author

@mprse @c1728p9 could you review

mprse
mprse previously approved these changes May 17, 2018
0xc0170
0xc0170 previously approved these changes May 17, 2018
@cmonr
Copy link
Contributor

cmonr commented May 17, 2018

/morph build

@bulislaw
Copy link
Member

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?

@mbed-ci
Copy link

mbed-ci commented May 17, 2018

Build : SUCCESS

Build number : 2052
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6935/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented May 17, 2018

@mbed-ci
Copy link

mbed-ci commented May 17, 2018

@cmonr
Copy link
Contributor

cmonr commented May 18, 2018

@maciejbocianski Could you answer @bulislaw's question?

@cmonr
Copy link
Contributor

cmonr commented May 18, 2018

/morph test

@mbed-ci
Copy link

mbed-ci commented May 18, 2018

@maciejbocianski
Copy link
Contributor Author

@bulislaw it's not critical, could be postponed.

@0xc0170
Copy link
Contributor

0xc0170 commented May 18, 2018

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?

Setting this as needs preceding PR.

@cmonr
Copy link
Contributor

cmonr commented May 29, 2018

@bulislaw Since HAL has landed, I take it this is clear to continue?

@@ -91,9 +95,12 @@ void test_multi_ticker(void)
}

Thread::wait(MULTI_TICKER_TIME_MS + TICKER_COUNT + extra_wait);
multi_counter_snapshot = multi_counter;
Copy link
Contributor

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?

Copy link
Contributor Author

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

0xc0170
0xc0170 previously approved these changes May 30, 2018
@0xc0170 0xc0170 requested a review from a team June 6, 2018 13:22
@0xc0170 0xc0170 mentioned this pull request Jun 7, 2018
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);
Copy link
Contributor

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?

Copy link
Contributor Author

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

c1728p9
c1728p9 previously approved these changes Jun 7, 2018
@cmonr
Copy link
Contributor

cmonr commented Jun 8, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jun 8, 2018

Build : SUCCESS

Build number : 2282
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6935/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

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
@cmonr
Copy link
Contributor

cmonr commented Jun 8, 2018

Pausing CI until 5.9 RC3 completes CI. Will restart jobs when able.

@mbed-ci
Copy link

mbed-ci commented Jun 8, 2018

@cmonr
Copy link
Contributor

cmonr commented Jun 12, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Jun 12, 2018

Build : SUCCESS

Build number : 2330
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6935/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Jun 12, 2018

@mbed-ci
Copy link

mbed-ci commented Jun 13, 2018

Test : SUCCESS

Build number : 2110
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/6935/2110

@cmonr cmonr merged commit 6999d25 into ARMmbed:master Jun 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants