_thread on RP2040 port not support more than 1 thread.

[water5]

import _thread
from utime import sleep

def test_1():
   while True:
      print('thread 1')
      sleep(1.5)

def test_2():
   while True:
      print('thread 2')
      sleep(1.5)

_thread.start_new_thread(test_1, ())
_thread.start_new_thread(test_2, ())

Traceback (most recent call last):
File "", line 1, in
OSError: core1 in use

[robert-hh]

That's intentional. The Pico port supports 1 thread per core. On the pro side this means, both threads run at full CPU speed.

[water5]

This caused by RP2040 hardware limit? is it possible implement multithread support in future release at RP2040 port?

[sosi-deadeye]

The ESP32 allow many threads.
Are there significant differences between the ports?
Why does the ESP32 allow more threads?

I see this question often in support forums for RPi.

[water5]

Yes, I already use multithread fine in ESP32 port.

[rkompass]

Are there significant differences between the ports?
Why does the ESP32 allow more threads?

Yes. On the ESP32 (likewise on ESP8266) Micropython inherits the threading from the FreeRTOS. This does not need many CPU cores but uses time-slicing. The ESP32 has two cores, but currently only one is used for Micropython. See #8197.

On the RPI Pico is no FreeRTOS. The threading is established as part of the MP port. You have the _thread library and can only use 1 other thread, except the current one. MP then runs in parallel on both cores. This is in a somewhat experimental state.
There were many discussion related to this, for example as to whether parallel access to same variables is problematic or not.
Mostly it is not on the basic level (change of a simple variable, which is atomic wrt the interpreter).
Interrupts on the second core are problematic. If the second core wants to signal something: There is the thread-safe flag.
Much more info is to be given here. The best would be an intensive search here on the forum, and perhaps in MP issues (and pull requests).

[peterhinch]

See this doc which I wrote with a lot of help from @jimmo. This para in particular aims to explain the issues with the GIL-free implementation.