@gmx
Thanks for that test snippet and it does highlight an issue with using print within a thread acquire and release. As you mention the lock appears to work as it gets released, eventually, though not all the printouts are made. Also the printouts are not made within the loop while the lock is on and only get output once the lock is released. I did try a smaller print by only printing the loop counter and that managed to get the 30 printouts though, again, only after the lock had been released.
If the lock is applied and released within the loop on core1 as per the loop on core0 than it does work, but of course that is not the point.
Based on your test snippet I then had a go with both cores appending items to a list. That worked, sort of. After the functions on both cores finish they print out the list. When both cores are in the process of simultaneously printing the printout gets mangled up.
So printing from both cores is an issue and will require care if trying to do this. This may be a minor issue so at this stage I am minded to continue to see how far I can get with using _thread, but your example was a very good example of the sort of issue I may well find.
In case its of interest I show the test code snippet on using both cores to amend a list (with locks applied as per your code)
Thanks for that test snippet and it does highlight an issue with using print within a thread acquire and release. As you mention the lock appears to work as it gets released, eventually, though not all the printouts are made. Also the printouts are not made within the loop while the lock is on and only get output once the lock is released. I did try a smaller print by only printing the loop counter and that managed to get the 30 printouts though, again, only after the lock had been released.
If the lock is applied and released within the loop on core1 as per the loop on core0 than it does work, but of course that is not the point.
Based on your test snippet I then had a go with both cores appending items to a list. That worked, sort of. After the functions on both cores finish they print out the list. When both cores are in the process of simultaneously printing the printout gets mangled up.
So printing from both cores is an issue and will require care if trying to do this. This may be a minor issue so at this stage I am minded to continue to see how far I can get with using _thread, but your example was a very good example of the sort of issue I may well find.
In case its of interest I show the test code snippet on using both cores to amend a list (with locks applied as per your code)
Code:
import time, _thread, machine, gcfrom machine import Pingc.collect()led = machine.Pin(25,mode=Pin.OUT,value=0)led.on(); time.sleep_ms(50); led.off()myLock=_thread.allocate_lock()long_list = []for num in range(100): long_list.append(num)print(long_list)def task1(): global myLock print("Core1 thread started") time.sleep_us(1000) count = 0 myLock.acquire() for i in range(30): long_list.append(('task1',i)) time.sleep_ms(50) myLock.release() print(long_list)def task0(): global myLock print("Core0 thread started") for i in range(100): myLock.acquire() long_list.append(('task0',i)) myLock.release() _thread.start_new_thread(task1,()) task0()print(long_list)# take a pause and then print long_list again# as the the previous print is mangled with# a simultaneous one from task1time.sleep(2)print(long_list)Statistics: Posted by SirFico — Sun Dec 08, 2024 5:06 pm