Java.math.BigDecimal toString is not thread safe

stringCache is only ever assigned to with an initialised string (the output of stringCache()), so given Strings are immutable and assuming Java's assignment is atomic, how can you get a race condition that causes a problem? There shouldn't be a TOCTTOU issue either given stringCache is copied to sc before being null-checked.

What is the statement reordering doing here to break this? How can it be prevented? (Does it need write barriers or something?)

Re: Java.math.BigDecimal toString is not thread safe

#7

Post by pwagland » Wed, Aug 30, 2017, 12:59 PM UTC

TazeTSchnitzel wrote: post #6

I don't understand the race condition here. stringCache is only ever assigned to with an initialised string (the output of stringCache()), so given Strings are immutable and assuming Java's assignment is atomic, how can you get a race condition that causes a problem? There shouldn't be a TOCTTOU issue either given stringCache is copied to sc before being null-checked. What is the statement reordering doing here to br…

Using the Java terminology, there is no "happens-before" edge. So every action must appear as if it occurred in the specified order in that thread, but other threads are free to see those actions in a different order.

On some machines/CPUs/architectures, this is very easy to organise, since the writes can and will be re-ordered. When this happens you can get the pointer to the string being set, before the contents of the string are actually set. Within the thread, you won't see this, since reorders within the thread of context are done "safely", or at least are visible, but to a different thread/core/CPU those writes may arrive out of order.

Re: Java.math.BigDecimal toString is not thread safe

#8

Post by hyperpape » Wed, Aug 30, 2017, 1:00 PM UTC

TazeTSchnitzel wrote: post #6

I don't understand the race condition here. stringCache is only ever assigned to with an initialised string (the output of stringCache()), so given Strings are immutable and assuming Java's assignment is atomic, how can you get a race condition that causes a problem? There shouldn't be a TOCTTOU issue either given stringCache is copied to sc before being null-checked. What is the statement reordering doing here to br…

You can see a partially constructed String is the problem. Assignment is atomic, but it's not guaranteed to not be reordered with operations done in the constructor.

The double checked locking is broken declaration describes this: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedL...

Edit: nevermind, I believe others' points about Strings having a final value make this irrelevant.

Re: Java.math.BigDecimal toString is not thread safe

#9

Post by joncrocks » Wed, Aug 30, 2017, 1:02 PM UTC

TazeTSchnitzel wrote: post #6

I don't understand the race condition here. stringCache is only ever assigned to with an initialised string (the output of stringCache()), so given Strings are immutable and assuming Java's assignment is atomic, how can you get a race condition that causes a problem? There shouldn't be a TOCTTOU issue either given stringCache is copied to sc before being null-checked. What is the statement reordering doing here to br…

The issue may be to do with the guarantees that the JVM gives you about orders of operations and write visibility across threads.

The author hints at a possible solution when they say "As we see a non-volatile field stringCache", the key being 'volatile' which is a Java keyword with a specific meaning that constrains the order of operations and write visibility across threads.

See http://tutorials.jenkov.com/java-concurrency/java-memory-mod... for a reasonable explanation.

edit: suggestion elsewhere that it could be a wonky JVM implementation, so may not be a BigDecimal problem after all

Re: Java.math.BigDecimal toString is not thread safe

#10

Post by dudul » Wed, Aug 30, 2017, 1:02 PM UTC

lozzo wrote: post #5

which version of Java ?

Seems to be at least until Java8