On Tuesday, 29 בNovember 2005 17:28, Caldarale, Charles R wrote: > > From: Oded Arbel [mailto:[EMAIL PROTECTED] > > Subject: Re: Java databases as alternative to MySQL on OS X > > Server? (OT) > > > > inter-thread communication in java is done through shared > > memory - shared variables, but the Java memory sharing model > > doesn't really share memory, Instead it uses thread local > > storage to store copies of shared variables and when you > > cross into or out of a synchronized block, the contents of > > the variables are copied. > > That's one of the most bizarre and blatantly wrong descriptions of > the Java memory model that I've ever read.
Rather simplified and not accurate where accuracy would have caused me to get way off topic, but all in all not really incorrect. > All Java objects reside > in the Java heap, which is shared across all threads of the JVM > process and directly referenceable by all. Please read up on your Java memory model. What you describe is a nice abstraction that many Java developers have in their mind, but is technically not correct and can't be correct when you consider multiple processors, DMA, hyper-threading or even just plain old L2 CPU caches. [http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html] [http://www.developer.com/java/article.php/951051] [http://www-128.ibm.com/developerworks/library/j-jtp02244.html] Also please note that JSR-133, once implemented, supposedly makes the whole discussion irrelevant as it forces read/write ordering. But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure about its correctness. > Entering a synchronized block in a HotSpot-based JVM normally does > not require any context switching, since the lock on an object is > established via the platform's compare-and-exchange instruction; only > if a conflict exists are kernel services required to suspend the > conflicting thread. You are obviously disregarding the fact that Java is a multi-platform environment, and some platforms (notably the Mac OS-X which started the whole thread) does not provide such a mechanism. Are you an MS-Windows programmer by any chance ? > No copying of local variable is ever > performed; If it ever appeared that I was talking about 'local variables' when I wrote the word 'local' then I'm deeply sorry, and I here-by request that you please re-read my original post more carefully. The word local in this case was used to denote the running thread's view on the shared variables, also knows as "thread local storage" (do look up that concept as well when you read about the Java memory mode, please). -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. When the student is ready the master appears. -- Japanese proverb --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
