RE: Programming style (was Accessors) revisited ; de-compiler ???
RE: Programming style (was Accessors) revisited ; de-compiler ???
- Subject: RE: Programming style (was Accessors) revisited ; de-compiler ???
- From: Victor Ng <email@hidden>
- Date: Fri, 16 Aug 2002 06:15:17 -0700 (PDT)
This is getting off topic from Cocoa, but hey - you asked. :)
On Thursday, Aug 15, 2002, at 08:44PM, Kevin Elliott <email@hidden> wrote:
>
>Not sure about Cocoa, but on Java if you're doing pointer comparisons you
>
>might get inconsistent results on multiprocessor machines (or just plain
>
>multithreaded enviroments) because different threads of control may cache
>
>local copies of objects for performance improvements.
>
>
Huh? That sounds incredibly strange. For this to be true the processor
>
would somehow have to be making a local copy of an object, moving stuff
>
around in memory and other assorted weirdness. Now, there are definitely
>
issues with access the same variable across two processors, but that's a
>
more general problem that pointer comparison.
Java is running on a virtual machine. The Java Language Specification defines a memory model that is not necessarily the same as the underlying machine. This is how you get your platform independence.
From the JLS itself
http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#30206
"Each thread has a working memory, in which it may keep copies of the values of variables from the main memory that is shared between all threads. To access a shared variable, a thread usually first obtains a lock and flushes its working memory. This guarantees that shared values will thereafter be loaded from the shared main memory to the threads working memory. When a thread unlocks a lock it guarantees the values it holds in its working memory will be written back to the main memory."
So yes - is it incredibly strange. :)
If you think of the JVM as your processor (which you should) - it is allowed to make local 'cache' copies of objects. There's no weird moving around of memory because you need to lock/unlock to force the memory copy.
On multiprocessor machines, I've seen this 'local copy' behaviour on dual processor Intel Linux boxes as well as 4-way SPARC machines for my own production code. Never quite got the problem to reproduce itself on a dual SPARC though.
The point here is that the JLS would allow even a single processor JVM to enable per thread caching (actually I think this does happen with Java 1.4) - so you must never distinguish between multi-threaded and multi-cpu enviroments when you're coding. Always assume the worst.
There is some work being done to revise the JLS and the Java memory model led by Bill Pugh and a bunch of others. For a lot of really really good information
http://www.cs.umd.edu/~pugh/java/memoryModel/
While we're on the topic of multithreaded Java, if you're you need the use of thread-safe collection libraries you should be using this one:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
I was burned BADLY by this stuff last year - it was a painful learning experience.
Other things that work in C++ but don't - double checked locking. Just google for it.
Victor "recalling a lot of pain right now" Ng
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.