Script using _thread was unsuccess! it's bug ?

[QiaoTuCodes]

i'll try useing mic_array boards to test this program :

from Maix import MIC_ARRAY as mic
import utime, _thread, gc

# init mic_array modules.
mic.init()
gLock = None

dir = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] # the leds state_array.
led_color_set = [0, 0, 255] # ws2812b color define.

def Process1():
   for i in range(1,7):
       dir[i - 1] = 255
       # on
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(80)
   for i in range(1,7):
       dir[i - 1] = 0
       # off
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(80)
       _thread.exit()
   gc.collect()



def Process2():
   for i in range(12, 6, -1):
       dir[i - 1] = 255
       # on
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(80)
   for i in range(12, 6, -1):
       dir[i - 1] = 0
       # off
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(80)
       _thread.exit()
   gc.collect()

def main():
   # leds clean
   for i in range(12, 6, -1):
       dir[i - 1] = 0 # useing zero turn off led_array this's atraversing method.
       # off
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(1)
   for i in range(1,7):
       dir[i - 1] = 0
       # off
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(1)
   print('----Process Start!----')

if __name__ == '__main__':


   while True:
       # create process1
       _thread.start_new_thread(Process1, ())
       # create process2
       _thread.start_new_thread(Process2, ())
       # create lock
       gLock = _thread.allocate_lock()
       # get lock
       gLock.acquire()
       main()
       # del lock
       gLock.release()
       # sleep sometime
       utime.sleep(1)
   mic.deinit()

all run it's good! but run 3 minutes and just shut down self, sometime is 5 minutes or more. it's not any info reply on _thread modules. i don't know why! what happed? program just be silent close self. somebody know that? whatever thank!
by the way, the program create and runing for sipeed MaixPy K210 dock boads and mic_array board. the firmware packaging with micropython v1.13. take a look here:
core_board https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html?highlight=k210%20dock
mic_array_board https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/module_microphone.html?highlight=mic_array

useing _thread effect video:

33fc9a75aa34b23aff4fa1159b4c84f8.mp4

[rkompass]

After a short inspection I see that your program has at least some bugs:

   for i in range(1,7):
       dir[i - 1] = 0
       # off
       mic.set_led(dir, led_color_set)
       utime.sleep_ms(80)
       _thread.exit()

Exiting from the thread in a loop should finish the thread immediately, why the loop then?
The code creating and acquiring gLock is another example: It does nothing, as the acquiration of a lock once just passes.
Doing a garbage collection in a thread is another possibly problematic thing. But this does not occur, as your threads exit before..

The micropython port to K210 is 'relatively' new. I just learnt that loboris did an independent port where he extended the threading capabilities. This seems to be inactive for over a year though.

I see problems here: You seem not to be familiar with threading. So no problem: studying it is interesting. I did it just a few weeks ago.
I did not find documentation of threads in the Sipeed MP port. They seem to have just a demo of threading which does only start two threads.
There do a few questions arise here: Is Sipeed MP threading based on FreeRTOS, like with ESP32? It seems so, but I'm not sure.
Then the threads probably are not truly parallel (unlike in the RPi 2040, which has only 2 truly parallel threads), which loboris's port seemed to have ??
In parallel with studying threading I would suggest that you try out, even explore the features that are available in threading.
As this MP port is relatively new I would expect some of the functionality not working properly.
You may try out the test programs that are included in MP first.
Then you may find several discussions of threads in the MP forum and here.
Again: I would not rely on the assumption that things that work on other ports of Micropython automatically work in the K210 port. Especially with such a subtle thing like threading.

[QiaoTuCodes]

see , check that, not support _thread.stop_thread(thread_id) method.

[QiaoTuCodes]

if you add print(_thread.get_ident()) , you'll notice that a process actually creates 6 thread_id and they don't repeat ,they keep increasing thread_id number. i think this's what causes the memory heap to overfill automatically ending ?

[QiaoTuCodes]

bandicam.2022-12-11.01-31-23-358.mp4

[rkompass]

O.k., I missed the global while loop.
A suggestion: Try

def mythread(rarg):
   for i in range(rarg):
       dir[i - 1] = 255
       mic.set_led(dir, led_color_set)    # on
       utime.sleep_ms(80)
   for i in range(rarg):
       dir[i - 1] = 0
       mic.set_led(dir, led_color_set)    # off
       utime.sleep_ms(80)
   _thread.exit()

So you have only one function for both processes. You can pass the range argument tuple at creation of the threads, and
do the garbage collection in the 1 second waiting time in the global loop.

if __name__ == '__main__':
   while True:
       _thread.start_new_thread(mythread, ((1,7,1),))        # create process1
       _thread.start_new_thread(mythread, (12,6,-1))         # create process2
       gLock = _thread.allocate_lock()                       # create lock
       gLock.acquire()                                       # get lock
       main()
       gLock.release()                                       # release lock
       gc.collect()
       utime.sleep(1)                                        # sleep sometime
   mic.deinit()

Still mic.deinit() will never be called, because it's outside a never ending loop.
What is the lock for? Do the mic functions require a lock for exclusion of parallel access? Then the threads would need to wait for this same lock too by inclusion of gLock.acquire() and gLock.release() .
It's a waste of resources to start the threads anew every second. They could also wait for a global flag to go down and go up again, like in the program here while being in a while True: loop, so their repeated activity could be controlled by this flag from the global loop.

while True:
    while not flag:
        idle()
    ...... do the actual  thread processing ...
    while flag:
        idle()

But restarting the threads should be possible, of course.
Perhaps the thread memory is not free'd completely after _thread.exit(). This you could test in a separate program that creates a thread which itself exits after, say, changing a variable. Creation of many such threads in succession should not deplete the memory.

[rkompass]

Perhaps you try this:

# test creation of many short-lived threads

import _thread
from time import ticks_us, ticks_diff, sleep_ms, sleep_us
from machine import idle

flag = False
res = [0, 0]
gLock = _thread.allocate_lock()

def th_add(i):
    global res
    gLock.acquire()
    while not flag:
        idle()
    res[i] += 1
    while flag:
        idle()
    gLock.release()  
    _thread.exit()

gLock.acquire()
for i in range(1000):
    gLock.release()
    _thread.start_new_thread(th_add, (0,))
    # _thread.start_new_thread(th_add, (1,))
    flag = True
    while res[0] <= i:    # while res[0] < i or res[1] < i:
        sleep_ms(5)       # this is faster than idle()
        # idle()
    flag = False
    gLock.acquire()
    if not i % 10:
        print(f'{i} ')

which creates 1000 threads which exit shortly afterwards (being noticed by the main loop).
On my pyboard sometimes it's running very fast for about 50 threads then slower, which I assume is the garbage collector collecting all those threads.