uheapq and atomicity

[dkeeney]

The docs for micropython.schedule promise that it will not interrupt fundamental python operations, with list-appending as an example.

Are uheapq operations (heappop, heappush) atomic in this context? They are implemented in C, and I would infer that that makes them atomic from Python's reference, but I am not certain.

It would be nice not to wrap all the heapq operations in mutexes.

Thank you,
David

[pythoncoder]

The intention of micropython.schedule is that all MicroPython code can safely be run. So multiple asynchronous routines (e.g. ISR's) each of which changes the heapq via code called by micropython.schedule should be safe. This is because code run by micropython.schedule can't pre-empt another micropython.schedule routine.

Given the fact that this is the purpose of micropython.schedule, I think any failure would be considered a bug.

[dkeeney]

How about if ISR and non-ISR code are both using the heapq? Wouldn't there be a possibility of race conditions?

I could wrap all heap operations in micropython.schedule calls, but then I would need some clever way to recover popped values, maybe using a simple list as a return value queue, since list appends are atomic.

Thank you,
David

[pythoncoder]

We need to be clear about the concept of "ISR code". Code run in a hard ISR context is in a different category from that in a soft ISR (code run by micropython.schedule is similar to soft ISR code). Modifying any MicroPython object in a hard ISR carries hazards: see the docs especially the section "Use of Python objects". A hard ISR can run at a point in time when a Python instruction is partially executed: this carries various hazards and could be expected to break a uheapq.

Soft ISR code will only run between MicroPython opcodes. If a uheapq instance is accessed by a single line of code, that access should be safe when competing with another access in a soft ISR context.

[pythoncoder]

[EDITED]
@dkeeney The issues here are rather more complicated than I realised.

For background you might like to see my query on GitHub and the response from Damien.

tl;dr My answer was right, but more by luck than by judgement