That's why i mentioned not "necessarily re-entrant".Deadlock is only one concern with Interrupt/multicore function access. Another is data consistency vs corruption.
As a rule anything which modifies hardware state does not take locks, and must be protected by yu if you are accessing the same hardware from both cores or irq/non-irq code.
pico_sync, pico_time (timers/alrms) and the queue_t functions are multi-core and IRQ safe (unless otherwise stated)
of course I am! there is no hardware re-ordering of memory accesses to IO region (or indeed in general). all hardware accesses by the SDK are volatile, but we don't generally include any memory (compiler or hardware) barriers in the raw hardware wrapping APIs. they ARE included where necessary in pico_sync etc.except I am not sure whether accesses to timer_hw members can be reordered or not on this platform - are you?
Statistics: Posted by kilograham — Sat Feb 24, 2024 9:08 pm