It does get presented that way, and for the most part it is. But like all other software it has bugs and sometimes features which are incomplete. Unfortunately '_thread' is one of those things, and it's a big thing when it comes to the RP2-range which supports it.I had no sense of what was going on behind the scenes of MicroPython. I has always viewed it as a complete project that has basically fully stabilized.
Same too for networking which appears to have some issues as well, where networking is the whole point of RP2 'W' variants.
But, on the whole, it's a fantastic, generally bug-free and stable, piece of work for such a small team of two.
Same here but some digging revealed some older Python documentation - https://docs.python.org/3.5/library/_th ... le-_thread - and MicroPython, though undocumented, also exposes the '_thread.lock.allocate_lock', '_thread.lock.acquire' and '_thread.lock.release' methods. I guess those are what need to be used, are what the Raspberry Pi Python SDK document alludes to.I have been scratching my head how a lock could prevent a race condition so long as both cores could attempt to lock at the same time. I had trouble seeing how a lock would not itself require a lock, and so on.
These locks are presumably implemented within MicroPython [ via Pico SDK, in chip hardware ], such that they are guaranteed atomicity. Then, once one has acquired a lock in one thread, the other, attempting to do the same, will be suspended until the one who has it releases it. These lock acquiring and releasing methods can then be wrapped around shared resources which need them.
Whether this is actually necessary or would solve threading issues I don't know. I am not convinced it will because I have seen reports of errors and weirdness where no shared resources are being used, so there are no locks which might need to be applied.
Statistics: Posted by hippy — Fri Dec 06, 2024 2:49 pm