better/cleaner way to do this _thread lock #16027
GM-Script-Writer-62850
started this conversation in
General
Replies: 2 comments
-
I don't see the need for two locks. Assume def set_time():
lock.acquire()
ntptime.settime()
lock.release() On core 1 while True:
lock.acquire()
# do work that requires a stable clock
lock.release()
# Clock might get updated before the next iteration |
Beta Was this translation helpful? Give feedback.
0 replies
-
I managed to make it a bit better... note that i sync time at 1 AM daily (unless wifi is down) lock class:
Running on core 0
Running on core 1:
|
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
-
I have 1 lock I use as a indicator to tell the second core to hold up I need you to wait a moment, then I use a second lock to tell core 1 you are good to go, then the locks released and the other core gets start going again, trying to read this feels like spaghetti
maybe i just need better variable names? suggestions?
i could just lock and unlock with every sleep call, but seems like unnecessary overhead and core 0 can wait 0.1 seconds or if core 1 is actually busy taking user input, that takes priority and core 0 can wait, but being able to await the 1st lock would be nice...
I have this in my
_thread
's loopthen i have this running on core 0
this is the lock class
Beta Was this translation helpful? Give feedback.
All reactions