Use a recursive mutex to prevent deadlocks on the same thread, in the case an IRQ races against the thread level (on the same core) when acquiring the atomic section (mutex may be taken but IRQs not yet disabled, then the IRQ waits forever trying to acquire the mutux).
Unlock the mutex if it was locked, not ifcore1_entry is still non-null, to fix the case where the second core finishes (and setscore1_entry toNULL) while the first core is in the middle of an atomic operation.

Edit: the two changes are now:

split out multicore lockout handling so it's only done when doing a flash erase/write
change the ATOMIC_SECTION macros so they use new mutex enter/exit functions that also disable/restore interrupts (atomically).

dpgeorge added the port-rp2 label

Jan 1, 2024

dpgeorge mentioned this pull request

Jan 1, 2024

V1.22 creating new thread leads to hangup#13288

Closed

Copy link

mendenm commentedJan 1, 2024

It works! At least the simple test script runs both processors and reports results form them.

Excellent.

projectgus reviewed

Jan 1, 2024

View reviewed changes

ports/rp2/mpthreadport.c OutdatedShow resolvedHide resolved

dpgeorge force-pushed therp2-fix-atomic-section branch fromd062a6f to130b4a9Compare

January 2, 2024 03:52

Copy link

MemberAuthor

dpgeorge commentedJan 2, 2024

I have changed this to use a new set of mutex functions that also disable/restore interrupts when obtaining/releasing the mutex.

dpgeorge mentioned this pull request

Jan 2, 2024

_thread module freezing whole device (RPI_PICO_W)#12980

Closed

dpgeorge force-pushed therp2-fix-atomic-section branch from130b4a9 to3586586Compare

January 2, 2024 05:52

Copy link

Contributor

projectgus commentedJan 3, 2024

New approach looks good to me!

dpgeorge added3 commits

January 3, 2024 15:58

rp2/rp2_flash: Lockout second core only when doing flash erase/write.

c3989e3

Using the multicore lockout feature in the general atomic section makes itmuch more difficult to get correct.Signed-off-by: Damien George <damien@micropython.org>

rp2/mutex_extra: Implement additional mutex functions.

8438c87

These allow entering/exiting a mutex and also disabling/restoringinterrupts, in an atomic way.Signed-off-by: Damien George <damien@micropython.org>

rp2/mpthreadport: Fix race with IRQ when entering atomic section.

dc2a4e3

Prior to this commit there is a potential deadlock inmp_thread_begin_atomic_section(), when obtaining the atomic_mutex, in thefollowing situation:- main thread calls mp_thread_begin_atomic_section() (for whatever reason,  doesn't matter)- the second core is running so the main thread grabs the mutex via the  call mp_thread_mutex_lock(&atomic_mutex, 1), and this succeeds- before the main thread has a chance to run save_and_disable_interrupts()  a USB IRQ comes in and the main thread jumps off to process this IRQ- that USB processing triggers a call to the dcd_event_handler() wrapper  from commitbcbdee2- that then calls mp_sched_schedule_node()- that then attempts to obtain the atomic section, calling  mp_thread_begin_atomic_section()- that call then blocks trying to obtain atomic_mutex- core0 is now deadlocked on itself, because the main thread has the mutex  but the IRQ handler (which preempted the main thread) is blocked waiting  for the mutex, which will never be freeThe solution in this commit is to use mutex enter/exit functions that alsoatomically disable/restore interrupts.Fixes issuesmicropython#12980 andmicropython#13288.Signed-off-by: Damien George <damien@micropython.org>