On 10/10/2020 22:18, Jonathan Wakely wrote: > On Sat, 10 Oct 2020 at 20:43, David Brown <david.brown@xxxxxxxxxxxx> wrote: >> Is this strategy guaranteed to work in gcc, or is it a case of "it works >> in a simple test, but might fail in a complicated program or with >> different flags" ? > > I think it works by design. My understanding is that users providing > their own implementation of those calls is fully supported. I think > that's partly why libatomic.so is a distinct library, and not just > part of libgcc_s.so. The docs aren't entirely clear about this, they > just say that if the compiler can't emit lock-free instructions for > the atomic operation "a call is made to an external routine with the > same parameters to be resolved at run time." But I think that "to be > resolved at run time" means that you can choose how those calls will > be resolved. > Thank you for that - this sounds like the way to go for my code. And I suppose I should file a bug report for the current libatomic that comes with gcc. It would be much better to have no support by default than to have the current spinlocks - as it stands, on a microcontroller like mine, it will all appear to work during development and most testing. But if in normal processing the code takes the spinlock and then there is an interrupt whose handler tries to access the same atomic (or at least one that shares the same lock), the interrupt handler will be stalled forever. David
