On 05/11/2012 02:46 PM, Jacopo Cappellato wrote:
>> The UtilCache objects *are* thread-safe. You will not get any
>> internal corruption inside UtilCache. That is all that can be guaranteed.
>>
>> What isn't thread safe, is that calling code may end up having
>> multiple instances for the same key, unless calling code is written
>> correctly.
>
> And so if these methods are thread safe all your comments below don't apply
> to the code I wrote:
but if 2 threads both want foo, *and* there must only be *one*
singleton foo value, without an external synchronization point, there
might be 2 foo values in the system. This can't be fixed with
anything internal to the storage system.
(I've wanted to add a UtilCache.getOrCreate(key, creator) method for a
while to solve this problem, but have never gotten around to it).
>>> Saying again. 2 threads could be running. One wants "foo", the other
>>> wants "bar". The first sees no value for "foo", starts generating the
>>> result, then calls map.put("foo", result). When map.put is running,
>>> it's doing a lot of separate, individual steps.
>>>
>>> Now, the second thread comes around, and calls map.get("bar"). The
>>> first thread is still running inside the put. The second thread is
>>> not in the synchronized block, so it went straight into map.get. And
>>> now you have 2 threads both running code inside that map that has no
>>> happens-before/happens-after guarantees, so now things blow up.
