Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: double to string causes divide by zero!

Philip Crotwell <email@hidden> wrote:

>The problem is that you really need to synchronize the
>FloatingDecimal.dtoa method, but that is hidden behind the vm's string
>operator overloading. And it could easily happen that some other
>thread, with a completely independent double and string, could cause
>the same problem. It is simply not possible to find all double to
>string conversions and syncronize them, especially when they may exist
>in external library code that you have no control over.

I don't see how synchronizing FloatingDecimal.dtoa() would make a
difference anyway.

The FloatingDecimal class always and only binds one instance to a specific
'double' value. Furthermore, Double.toString(double) consists of:
public static String toString(double d) {
return new FloatingDecimal(d).toJavaFormatString();
}

That is, every call in every thread gets its own instance of
FloatingDecimal. So even if FloatingDecimal DID work with multiple double
values over the lifetime of a single instance, that's not how
Double.toString() is using it.

The only possibility for inter-thread interference in FloatingDecimal would
be if there were unprotected writable static variables. Scanning the
source for FloatingDecimal, however, one sees only final static variables,
or static variables properly protected by a 'synchronized' method (e.g. b5p
and big5pow()).

Another hypothesis, based on the (non-)atomicity of longs and doubles,
doesn't apply here, because all the references to longs or doubles in
FloatingDecimal are either read-only (final variables) or are synchronized.
The only time non-atomicity could possibly matter is when the value is
being changed. If it doesn't change, then the value's atomicity is
irrelevant. Regardless of when you read the pieces of it, the bits being
read are always the same.

Examining the code for FloatingDecimal.dtoa(), one finds that the
line-number cited in the stack-trace has a long division of two local
variables. Local variables aren't shared between threads, so neither
synchronization, volatility, nor atomicity matters.


Rob Ross wrote:

>> synchronized (this) {
>> double d = some special double
>> String s = "";
>> s+=d;
>> }

This shouldn't make any difference, as explained above. Nor would
declaring the 'double' as volatile, nor any other Java-language tricks.

The problem exhibited by the original code is not that there's a double or
any other apparent object being shared by two threads. Hence, any attempt
to fix the problem by synchronizing the threads is not addressing the real
problem.

The problem appears to be that something in the JVM/JITC or other
implementation is incorrectly sharing some data between two threads, even
though it shouldn't be. That implies a bug in the JVM or JITC, and since
the bug only appears on a G5, which uses 64-bit opcodes for long division
(see the archives), that's where I'd place my money.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.