Are you saying that MicroPython does handle contention, atomicity, etc? Or that it should?There's nothing I have seen which would lead anyone to think that MicroPython doesn't handle the nitty-gritty of contention, atomicity, locks, mutexes and whatever, itself. Which is what would be expected.
Does CPython handle contention, atomicity, etc? As far as I understand it, it leaves that to the underlying OS. MicroPython has no OS to rely on for those features. Of the multi-core ports (excluding unix) that MicroPython runs on:
- m.iMX RT doesn't support _thread at all
- ESP32 (on dual core hardware) reserves one core for FreeRTOS, and all user code runs on the other. So while FreeRTOS does handle multi-core contention, etc, properly, you never get to run your _thread on another core
- rp2 starts _thread on the second core, but leaves everything about contention, etc, up to you. Which most programmers (including me) aren't used to dealing with, and they have a sad when it goes wrong.
As for the "TinyUSB callback can't recurse" problem, there is a PR in to fix it, but it looks like it needs other work. It's not attached to any milestone, so its implementation isn't likely to be any time soon: usb,rp2: Fix "TinyUSB callback can't recurse" error when using threads. by projectgus · Pull Request #15448 · micropython/micropython
I do see that I could be (slightly) accused of trying to absolve MicroPython of any problems. I am trying hard not to do that. I feel that MicroPython is often oversold as "Python for micro-controllers", when it's really "A language with Python-like syntax for very small systems: be delighted that anything works at all"
Statistics: Posted by scruss — Wed Jul 31, 2024 5:15 pm
