The micropython doc simply states "This module is highly experimental and its API is not yet fully settled and not yet described in this documentation." and suggests "For more information, refer to the original CPython documentation: _thread."
So not much help there![:)]( "Smile")
and due warning for any wanting to dip their tootsie into the soup. But one can't say the Micropython team has not given fair warning.
The only good ref I find on actually using _thread for real is mentioned in the docs and tutorials on aysncio by Peter Hinch:
https://github.com/peterhinch/micropyth ... iple-cores
And I put the section here for quick ref.
1.4 Threaded code on multiple cores
Currently this applies to RP2 and Unix ports, although as explained above the thread safe classes offered here do not yet support Unix.
1. There is no common GIL. This means that under some conditions Python built in objects can be corrupted.
2. In the code sample there is a risk of the asyncio task reading the dict at the same moment as it is being written. Updating a dictionary data entry is atomic: there is no risk of corrupt data being read. In the code sample a lock is only required if mutual consistency of the three values is essential.
3. In the absence of a GIL some operations on built-in objects are not thread safe. For example adding or deleting items in a dict. This extends to global variables because these are implemented as a dict. See Globals.
4. The observations in 1.3 re user defined data structures and asyncio interfacing apply.
5. Code running on a core other than that running asyncio may block for as long as necessary.
So adding or deleting global variable can cause havoc when using _thread, but how many folk who have a play with _thread on a pico have this in the forefront of their mind. It makes me wonder how many of the 'issues' with using the second core on the Pico is due to a lack of understanding how this should be implemented which is not unsurprising due to the complete lack of official documentation. I see Peter says "for example adding or deleting items in a dic", which rather implies there are more examples to be found ... not very encouraging I must say.
There is a ThreadSafeFlag to be found in the asyncio module. Ploughing back of some stuff with a google appears it may have resided in some other module in the past but was moved for CPython compatibility.
I'm not implying that the _thread module is robust but I do wonder if one can navigate around the pitfalls, albeit they are very easy to step into, that making good use of the Pico second core in MP is actually worth having a go at. Its certainly to be considered a no-go for beginners and the rpi docs for beginners are remiss in promoting multicore programming at this point in time.
I've not got a project for a Pico in mind at this time that warrants using the second core but I may have a bit more of a delve into this to have a play when I'm in an idle code playing mood to see how far I get, though, from the above posts it may not be long before grinding to a halt with inexplicable random freezes. I will probably find out the hard way![:)]( "Smile")
So not much help there
and due warning for any wanting to dip their tootsie into the soup. But one can't say the Micropython team has not given fair warning. The only good ref I find on actually using _thread for real is mentioned in the docs and tutorials on aysncio by Peter Hinch:
https://github.com/peterhinch/micropyth ... iple-cores
And I put the section here for quick ref.
1.4 Threaded code on multiple cores
Currently this applies to RP2 and Unix ports, although as explained above the thread safe classes offered here do not yet support Unix.
1. There is no common GIL. This means that under some conditions Python built in objects can be corrupted.
2. In the code sample there is a risk of the asyncio task reading the dict at the same moment as it is being written. Updating a dictionary data entry is atomic: there is no risk of corrupt data being read. In the code sample a lock is only required if mutual consistency of the three values is essential.
3. In the absence of a GIL some operations on built-in objects are not thread safe. For example adding or deleting items in a dict. This extends to global variables because these are implemented as a dict. See Globals.
4. The observations in 1.3 re user defined data structures and asyncio interfacing apply.
5. Code running on a core other than that running asyncio may block for as long as necessary.
So adding or deleting global variable can cause havoc when using _thread, but how many folk who have a play with _thread on a pico have this in the forefront of their mind. It makes me wonder how many of the 'issues' with using the second core on the Pico is due to a lack of understanding how this should be implemented which is not unsurprising due to the complete lack of official documentation. I see Peter says "for example adding or deleting items in a dic", which rather implies there are more examples to be found ... not very encouraging I must say.
There is a ThreadSafeFlag to be found in the asyncio module. Ploughing back of some stuff with a google appears it may have resided in some other module in the past but was moved for CPython compatibility.
I'm not implying that the _thread module is robust but I do wonder if one can navigate around the pitfalls, albeit they are very easy to step into, that making good use of the Pico second core in MP is actually worth having a go at. Its certainly to be considered a no-go for beginners and the rpi docs for beginners are remiss in promoting multicore programming at this point in time.
I've not got a project for a Pico in mind at this time that warrants using the second core but I may have a bit more of a delve into this to have a play when I'm in an idle code playing mood to see how far I get, though, from the above posts it may not be long before grinding to a halt with inexplicable random freezes. I will probably find out the hard way
Statistics: Posted by SirFico — Thu Dec 05, 2024 9:39 pm