As current implementation is not thread safe, I think that we can choose to make thread safety the default behavior or not, it doesn't matter.
A default implementation that is not synchronized and a mechanism to allow a thread safe Rhino makes sense for me. I imagine that an additional Context feature flag could be used for this purpose. Nevertheless this would be a bit more work than just calling Collections.synchronizedMap() as for instance iterations on the collection views need to be synchronized on the map too. Furthermore this only concerns ScriptableObject and I doubt that all other classes are already thread safe. I can modify my patch that introduces the usage of a Map to hold properties in ScriptableObject to make it thread safe or optionally thread safe if we agree on a mechanism for that. Cheers, Marc. -- Blog: http://mguillem.wordpress.com Attila Szegedi wrote: > 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
