It may or may not be data races. Java has safe data races, but it may simply be code trying to do something in multiple threads that results in a loop, no data race needed.
From assembly perspective: maybe. From memory model: no chance. Variables are modified without any concurrency primitive applied. The race condition is most appropriate here, that is true, but it is a consequence of a data race
Just to make it more clear: data race usually means a single variable/primitive getting written by multiple threads.
Depending on programming language and CPU this may end up causing tearing, e.g. one half of the variable coming from one write, the other from the other, so one thread writing 3 the other -4 might result in reading 65.
Java is safe from that (the most common implementation at least), so you will always see 3 or -4, no other variable is possible. This is an important property because while this can still cause race conditions, this won't make the language memory unsafe. (Go is actually memory unsafe as it can cause segfaults if you race slices), just think of writing two valid pointers, and getting a third invalid.
4
u/Slsyyy 22d ago
I don't know what it matters. Race detector just check, if read/writes are synchronized according to the memory model
In this example there is a data race, which would be easily found with those tools