Yes, the GIL limits a system to only running one thing at a time which automatically means no thread can be tampering with any data another thread may be using; essentially all data operations become atomic.Somehow it's still difficult.
That of course stalls threads while another gets its shot at executing for a while. That's fine and how it has to be when single core, but having multiple cores should mean threads shouldn't have to stall except when it comes to interacting with data where atomicity is still required.
The issue as I understand it is that disabling the GIL will allow concurrent threads to run on multiple cores, but that also takes away the guarantee of data interaction atomicity. So without an additional mechanism to ensure that atomicity things quickly go to pot.
The complexity of data items in Python and MicroPython is they are rarely a single byte or word entities, but huge structures of things including pointers to other data items, reference counts to enable garbage collection, with management pools to keep track of things. The whole lot needs to be kept consistent while data is updated, needs to remain consistent while data is used.
And it seems there is some failing with that for MicroPython which causes it to trip over itself, though I am not sure of the exact details.
Statistics: Posted by hippy — Wed Nov 27, 2024 7:29 pm