968981 wrote:Eh? If you repeat the question I'm just going to repeat the answer:
How do you know this is not thread safe?
The map can still be altered by another thread while this code is running through it. So no, it is not guaranteed thread safe.But I said not guaranteed. I can't make any claims based on a very non-specific question devoid of context other than that it is a "multithreaded environment".
968981 wrote:In practice it isn't possible to test it, for exactly the same reason it isn't possible to prove it. Often the way you will find out that you have thread-safety problems is that strange things start to happen on your server when it is heavily loaded.
P.S. I wasn't asking you to personally prove it. I was asking theoretically what one would do if they wanted to test this scenario. : )
968981 wrote:No, it isn't. For one thing "return absolutely precise values" is a phrase which doesn't really mean anything in a multi-processing world. For example, in a multi-processing world you can't even tell which of two events happened first unless you do some careful processing to make that clear. When you read the API docs for the java.util.concurrent package you'll see the phrase "happen-before" mentioned frequently, with a link to a densely-written chunk of text which refers to a chapter of the Java language spec.
If results from this method must return absolutely precise values, a best practice would be to either place a synchronized keyword on the method or refractor the method into an instance method, instead of a static method.
Is this a fair conclusion?