-
Notifications
You must be signed in to change notification settings - Fork 195
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
Rework locks #2197
Rework locks #2197
Conversation
740fb61
to
ef89ed8
Compare
c1abe1b
to
d6af970
Compare
Fun fact: this PR came 2 days before #797 turned one year old :D |
I expect you to mark this occasion in your calendar for next year too :D |
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.
Nice!
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.
LGTM, I'm glad we're reusing code for both the stand alone lock and CS now.
It would be nice to have a test or two, but we can leave that for now. One final thing to consider before merging, what about naming the lock module sync
instead?
It's private, we can deal with this later, when we're fixing the fallout from this 🤣 |
This change should prevent multi-core apps spinning in interrupt-free context if the other core is holding the global lock.
It's hardly a stress test, but I've ran the multicore examples on an ESP32 and they worked as expected.