On May 11, 2012, at 9:51 PM, Adam Heath wrote: > 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. >
Yes, of course if you rely on this mechanism to figure out if you need to run a critical initialization that has to run only *one* time (a singleton, some special file creation, db operations, communication with external systems etc...) you definitely need an external mechanism of synchronization. But this is not the case here and for this reason your comments don't apply to the code I wrote (there is no harm at having two instances of the same parsed script here, it is just a small waste of cpu that I was aware about and it is acceptable). Jacopo
