Android static_assert on juce::Atomic<> fails on build


Hello all,
I am trying to build an Android project and I am getting this error (Android Studio 3.0.1, JUCE 5.2.0):

Error:(57, 10) error: static_assert failed "This class can only be used for lock-free types"

Information:(100, 5) in instantiation of member function 'juce::Atomic<int>::~Atomic' requested here **

The JuceDemo builds fine, so I know it is something I overlooked but don’t know what! I haven’t explicitly used any juce::Atomic<>, so what could trigger this error? Any help would be very appreciated!

UPDATE: the project builds fine with 5.1.2 without changes.



Could you use git bisect to find the commit that changed the behaviour? That should tell us what’s going on.


Hi team!

Thanks for looking into this. I’m getting a very similar error with Android Studio 3.1.2 and the latest develop. I’m also not using any atomics directly. After a couple of hours’ bisection, I discovered that the following commit caused this: 057bb262ddb45f762ab1cc08da6ac44e74b65c04
which makes sense, since that’s precisely where std::atomic was enabled for Android. I hope this helps narrow down the problem?


Are you using the latest toolchain within Android Studio?


Hi @t0m.

Thanks, yes I am, although the result is consistently problematic with various older versions of the toolchain components too. I’m on Windows 10.

It seems that the issue continues to be whether or not an “Android” int is lock-free for atomic operations, as demanded by ReferenceCountedObject. The standard library is certainly bringing this into question, and I suppose some of the many Android architectures may not come to the lock-free int party. As a result, JUCE is complaining about this lack of guarantee, so it’s clearly a problematic assumption on some level. Meanwhile I have commented out this single static_assert and everything works fine for me on the few platforms I have tested, but they all feature atomic int operations anyway.

I suppose my main question is: do operations on int really need to be absolutely guaranteed lock-free for ReferenceCountedObject to function correctly, to the point where it forces a build to break? Are there certain deadlock-style situations to guard against due to its design or is it simply a performance concern? And if it is a serious problem, could we fall back to a smaller-sized numeric value, as code that has hundreds or millions of references to a single object is probably broken in some other way? This whole discussion feels like overkill though!

In any case, I would be happy with some minor spinning on certain platforms if it means the code will actually compile on any of them. Of course it would be nice to standardise reference counts over to shared_ptr which would render this whole discussion moot; I see there is a move in this direction already so I’m keen to see how it plays out in the long term.