-
Notifications
You must be signed in to change notification settings - Fork 63
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
Test SCHED0021 has a race condition #42
Labels
Comments
lsf37
added a commit
that referenced
this issue
Aug 21, 2021
These are currently BREAKPOINT_002 and SCHED0021. The corresponding issues #43 and #42 remain open, and when resolved positively, these tests should be enabled again for simulation runs. Signed-off-by: Gerwin Klein <[email protected]>
lsf37
added a commit
that referenced
this issue
Aug 21, 2021
These are currently BREAKPOINT_002 and SCHED0021. The corresponding issues #43 and #42 remain open, and when resolved positively, these tests should be enabled again for simulation runs. Signed-off-by: Gerwin Klein <[email protected]>
lsf37
added a commit
that referenced
this issue
Aug 21, 2021
These are currently BREAKPOINT_002 and SCHED0021. The corresponding issues #43 and #42 remain open, and when resolved positively, these tests should be enabled again for simulation runs. Signed-off-by: Gerwin Klein <[email protected]>
lsf37
added a commit
that referenced
this issue
Aug 23, 2021
These are currently BREAKPOINT_002 and SCHED0021. The corresponding issues #43 and #42 remain open, and when resolved positively, these tests should be enabled again for simulation runs. Signed-off-by: Gerwin Klein <[email protected]>
lsf37
added a commit
that referenced
this issue
Aug 23, 2021
These are currently BREAKPOINT_002 and SCHED0021. The corresponding issues #43 and #42 remain open, and when resolved positively, these tests should be enabled again for simulation runs. Signed-off-by: Gerwin Klein <[email protected]>
lsf37
added a commit
that referenced
this issue
Oct 27, 2023
Decrease the chance that the monitor thread is preempted just when it has released the preemption threads, but before it has yielded itself. (If that happens, the preemption threads get two time slices.) See also #42 Signed-off-by: Gerwin Klein <[email protected]>
Indanz
pushed a commit
that referenced
this issue
Oct 27, 2023
Decrease the chance that the monitor thread is preempted just when it has released the preemption threads, but before it has yielded itself. (If that happens, the preemption threads get two time slices.) See also #42 Signed-off-by: Gerwin Klein <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Isn't there a tiny chance that the preemptive scheduler will kick in after
test_simple_preempt_start = 1
? So all threads get their time slice to run. ThenseL4_Yield()
is executed and each thread again gets a time slice to run?Wouldn't is be better to do this:
There is still a risk because we can't be really sure what
time_now(env)
does and how long this may take.Aside from this, the line
is the original code seems quite useless to me, as nobody is using the value assigned to
now
, it is overwritten a few lines later. This might be a left over from a time where another debug message was printed with it?The text was updated successfully, but these errors were encountered: