Skip to content

Timer race condition #243

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.

Sign up for GitHub

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

Jump to bottom
Merged
kilograham merged 1 commit into from
Mar 10, 2021
Merged

Timer race condition #243

kilograham merged 1 commit into from
Mar 10, 2021

Conversation

@kilograham
Copy link
Contributor

@kilograham kilograham commented Mar 8, 2021

fixes #195

@kilograham kilograham force-pushed the timer-race-condition branch from 367eb34 to e2968db Compare March 8, 2021 21:47
@kilograham
hardware_timer: fix race condition whem a new timer being added becom…
1e658f2 
…es missed thus obviating the need for an IRQ but there is an IRQ already pending for another timer
@kilograham kilograham force-pushed the timer-race-condition branch from e2968db to 1e658f2 Compare March 8, 2021 21:49
@kilograham kilograham requested a review from Wren6991 March 8, 2021 21:50
@kilograham kilograham added this to the 1.1.1 milestone Mar 8, 2021
@kilograham kilograham linked an issue Mar 8, 2021 that may be closed by this pull request
Repeated invocation of function "void sleep_us(uint64_t us)" can cause lockup #195
Closed
lurch
lurch reviewed Mar 8, 2021
View reviewed changes
Wren6991
Wren6991 approved these changes Mar 10, 2021
View reviewed changes
Copy link
Contributor

@Wren6991 Wren6991 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the failure mode was an alarm firing at the point we were in the critical section setting an immediately-expiring timer on the same alarm, and getting dropped as a result?

@kilograham
Copy link
Contributor Author

kilograham commented Mar 10, 2021

So the failure mode was an alarm firing at the point we were in the critical section setting an immediately-expiring timer on the same alarm, and getting dropped as a result?

setting an immediately expiring timer when there was already a timer that had fired but not yet been serviced (because we were under lock)

@kilograham
Copy link
Contributor Author

kilograham commented Mar 10, 2021

note it also requires a mix of timers adding in IRQ (i.e. repeating) and non IRQ contexts (we already had a test which created a huge number of timers with random timeouts and makes sure they all happen and in the right order - just none of those repeated)

@kilograham kilograham merged commit d36b1ca into develop-1.1.1 Mar 10, 2021
@kilograham kilograham deleted the timer-race-condition branch March 10, 2021 18:04
@lurch lurch mentioned this pull request Mar 12, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@lurch lurch lurch left review comments

@Wren6991 Wren6991 Wren6991 approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

1.1.1

Development

Successfully merging this pull request may close these issues.

Repeated invocation of function "void sleep_us(uint64_t us)" can cause lockup

4 participants

@kilograham @lurch @Wren6991