Race condition in CTimer::PollKernelTimers #404
Closed
renebarto
started this conversation in
Development
Replies: 3 comments
-
|
Hi Rene, yes, that's an issue. I fixed it on the develop branch. The KY040 was the only place in Circle, where this could happen, because |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
This fix is in Circle 46. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks Rene
Met vriendelijke groet / Kind regards,
Rene Barto
Op wo 28 feb. 2024 09:40 schreef Rene Stange ***@***.***>:
… This fix is in Circle 46.
—
Reply to this email directly, view it on GitHub
<#404 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQY5NMTEMMWR3POS2MVXWTYV3UQXAVCNFSM6AAAAAA57RBNJ6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DMMJVGI2DQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Rene,
I'm continuing my venture on Circle. I Worked on the KY040 rotary switch, and found that, next to issues with the device itself, it causes a race condition.
When two timers are present, and the first one is deleted in a callback of PollKernelTimers due to a CancelKernelTimer call, the ptr list changes, and then the next pointer which was saved, is no longer correct.
I changed this such that after PollKernelTimers reclaims the spinlock, we start at the beginning of the list again. This way the list is correctly pointed to again
void CTimer::PollKernelTimers (void)
{
m_KernelTimerSpinLock.Acquire ();
#ifndef NDEBUG
pTimer->m_nMagic = 0;
#endif
delete pTimer;
}
I hope this is suffciently clear.
Thanks again, regards,
Rene Barto
Beta Was this translation helpful? Give feedback.
All reactions