I don't normally ping, but I think there is a significant issue here.

It concerns professional applications where reliability is paramount. Knowing that small int access is atomic, the programmer might think a global provides a safe way to return data from a hard ISR. I was surprised to learn from @jimmo that this is not guaranteed.

Is there a safe way to return a small int from a hard ISR short of using (e.g) a threadsafe queue?

Sorry I missed this in January @peterhinch . I think this is a good improvement, and is a lot better than what was there before.

You are of course correct, we really need to nail down the semantics of what is and isn't defined behavior in the face of hard IRQs, and now that we're supporting GIL-less multithreading on the rp2 the same applies there too (but with a lot more scope for problems!).

It concerns professional applications where reliability is paramount. Knowing that small int access is atomic, the programmer might think a global provides a safe way to return data from a hard ISR. I was surprised to learn from @jimmo that this is not guaranteed.

My understanding is that your updated wording is correct. It is safe to write a small int to a global variable (or a class attribute *) as long as there is no chance the underlying dictionary can be in the middle of a re-hash when the IRQ fires.
This will be the case as long as the code does not define new or delete existing globals.

• It's important that the IRQ finds the class instance via a closure around self, or equivalent, and not via globals!). e.g.

a = 0
b = SomeClass()

def on_irq(p):
  a = 1 # bad, 
  b.attr = 2 # also bad

def main():
  ...
     if something:
       c = True   # c global is created in the middle of the program's execution, might cause rehash which makes access to `a` and `b` invalid in ISR.

class Ok:
  def __init__(self):
    def on_irq(p):
      self.attr = 1 # safe as long as this instance's dict isn't changing, doesn't matter what's going on with globals

(So, for example, ThreadSafeFlag is safe).

I'm fairly sure a closure around a local would be safe to. @dpgeorge would need to confirm.

def main():
  a = 0
  def on_irq(p):
    a = 1

Is there a safe way to return a small int from a hard ISR short of using (e.g) a threadsafe queue?

Specifically for the case of returning a small int, it should always be possible to find some shared scope to put the small int on. Maybe I'm misunderstanding the question though? i.e. if you explicitly want to be able to queue up multiple interrupts worth of values to application code that consumes them asynchronously?

Even if you had some sort of ISR-safe queue, you still need a way to access the queue. (As you say in the new wording in this PR, accessing a global for read from an ISR is still a problem). It's implementing an ISR-safe queue that's the hard part!

Thank you. I think for most applications the aim should be to define all globals (including class instances) before initiating hard IRQ's - and never to delete globals.

You might want to comment on #9458 - a possible ISR-safe queue.

I agree this is an issue that needs clarifying.

But maybe we can improve the situation so it "just works". See #11604 for an attempt at that, which makes rehashing atomic wrt IRQ handlers.