Is .NET double.ToString threadsafe?

Question

I'm seeing an issue in a production ASP.NET application that involves the following code, which is used to render the geocoordinates of a particular object:

private double _longitude;
private double _latitude;

public string ToCsvString()
{
    return _latitude + "," + _longitude;
}

Thread.CurrentThread.CurrentCulture will be set to different values based on the incoming request. The behavior I'm seeing is that the result of this function will vary independent of the threadlocal culture. At times the decimal points and commas are incorrect for the current culture. More strangely, it seems that once set wrong, the wrong value persists.

Does ToString on double cache values?

Answer 1

Why not use the explicit ToString methods which allow you to manually specify a culture-specific IFormatProvider?

Answer 2

It shouldn't cache the values, especially because of the culture issue you mentioned. Two things come to mind:

1. How/where do you set the culture? Perhaps there is a bug there?
2. Are you sure it is THIS place that creates the bug? Perhaps the culture is different than you think? Perhaps the results of this function are cached elsewhere in your code?

Answer 3

For rendering geocoordinates, I suggest that you best define your own fixed formatting or culture rather than leaving it for the framework, default culture setting or culture info of the running thread.

I would do it like this to format it to 4 decimal points:

return _latitude.ToString("0.0000") + "," + _longitude.ToString("0.0000");

or

string.Format("{0:0.0000}, "{1:0.0000}", _latitude, _longitude);

Or if you want the decimal separator to be culture specific,

CultureInfo ci = System.Globalization.CultureInfo.GetCultureInfo("en-AU");
return _latitude.ToString("N4", ci) + "," + _longitude.ToString("N4", ci);

Answer 4

If you always want Double.ToString to return consistent values regardless of culture, use an InvariantCulture:

someDouble.ToString(CultureInfo.InvariantCulture); 

Answer 5

Operations such as ToString on double or any other immutable object are by definition thread safe. Since you are guaranteed that the state of those object never change an operation will always yield the same result, that result might however be based on the environment it's executed in but it will always yield the same result in the same environment. Since there are no side effects on immutable types ToString cannot cache the result