[denormalfloat]

I found it surprising that atomic operations in Java are converted in to locking when compiling for some versions of android. The guarantees of Java (before 9) on ordering are slightly too strong and result in locks being used under the hood.

[jillesvangurp]

Interesting. This probably is because of some hardware limitations on some older android hardware platforms.

The java.util.concurrent package was added in Java 5 and before that existed as a third party library (by Doug Lee). It contains a lot of concurrency primitives and makes use of a lot of things, including lock free instructions and optimistic locking: https://en.wikipedia.org/wiki/Java_concurrency

[MaxBarraclough]

That would open the door to thread-starvation, right? Unlikely in practice, but the point being that it does affect the formal correctness of the algorithm.

I imagine it also impacts real-world performance, but lock-free algorithms aren't assured to be faster anyway.

Annoyingly I recall reading a good article on exactly this question - the importance of hardware atomics vs locking - but can't recall what it was. These locks still aren't as bad as ad-hoc locking, in terms of deadlock risk, as you're guaranteed that they are 'leaf locks', with no order-of-acquisition hierarchies/orderings to worry about.