Nope, it isn't thread safe. And it's a very good question whether it should be. Just to bring up a familiar example -- HashMap. It is not thread safe. It can be made thread safe by wrapping it in a Collections.synchronizedMap(), but on its own it isn't.
In all sincerity, It's a rather nontrivial design decision. Thread safety implies additional synchronization[1], which OTOH isn't needed when you're not sharing your runtime objects across threads. I know how modern JVMs can optimize away certain synchronizations, but in case of a open-use library with lots of potential caller sites (such as Rhino), you'll bet the abilities of the JVM optimizer are soon outgrown. So, not all people will need it. Actually, I was just speaking with Kirk Pepperdine on the phone and we discussed some odds and ends of the Java Memory Model and I asked his opinion on this. (Kirk is one of leading Java performance tuning experts on the planet and I'm honored to be able to call him a good friend of mine.) He thinks that the HashMap example is one to follow -- don't make a general-purpose data structure thread safe, but allow it to be made thread safe somehow when needed. I consider Rhino ScriptableObject and friends to be a "general-purpose data structure", as it is part of a library of a rather, well, general purpose. I myself would've leaned toward making code thread safe before I spoke with Kirk. My reasoning is that synchronization is relatively cheap nowadays. It is still not free, however, as you'll necessarily cross a memory barrier and need to invalidate (on entry) and flush (on exit) the CPU L2 caches. And that's where Kirk speaks from his experience that we shouldn't oversynchronize it but rather try to make thread safety an external, optionally elected aspect. Let's keep this discussion going. Attila. [1] Or, alternatively, clever lock-free data structures, which can be a nightmare to maintain long-term as their implementations are often non-intuitive and hence easy to break when subsequently touched. Witness Cliff Click's lock-free threadsafe hashmap at <http://sourceforge.net/projects/high-scale-lib >, which uses an internal state machine and timing(!) aspects of the execution for correct behavior. It is a piece of genius work, but Cliff is not surprisingly considered the only person on the planet to actually fully understand it :-) But the darn thing actually scales on his company's (Azul Systems) 256-and-beyond CPU systems :-) On 2008.01.21., at 8:54, Marc Guillemot wrote: > Norris Boyd wrote: >> On Jan 19, 9:42 am, Christophe Grand <[EMAIL PROTECTED]> wrote: >>> Norris Boyd a écrit : >>> >>>> We do need >>>> thread safety in the default implementation as the previous >>>> implementation was used in multithreaded environments. >>> Speaking of thread-safety, which properties do you want to >>> guarantee/enforce? (I was surprised by some synchronized >>> statements in >>> NativeArray.) >>> >>> Christophe >> >> Operations on objects should be atomic, so reading a property or >> writing a property should be unaffected by other operations on the >> object from another thread. > > I really don't think that current implementation of properties > access in > ScriptableObject is thread safe ;-( > > Cheers, > Marc. > -- > Blog: http://mguillem.wordpress.com _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
