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: Kevin Elliott <email@hidden>
- Date: Thu, 15 Aug 2002 20:44:26 -0700
>
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.
I.E.. The following scenario will result in a deadlock on most MP
architectures:
Thread 1 does:
myVar= 10
while Thread 2 is doing:
while(myVar<10);
But even this issue isn't really the processor's fault. The compiler is
sticking myVar into a register (on thread 2) and never checking memory
again. This situation could certainly occur with pointers but it is not
strictly a pointer problem.
-Kevin Elliott
Software Engineer
CharisMac Engineering
>
----------
>
From: Victor Ng
>
Sent: Thursday, August 15, 2002 18:14
>
To: cocoadev
>
Subject: Re: Programming style (was Accessors) revisited ;
>
de-compiler ???
>
>
I'm a newbie to Cocoa and Objective-C, but I know this problem from the
>
Java
>
world.
>
>
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.
>
>
The reason it will depend on your processor is that those kinds of
>
optimizations fall into the realm of how the computer's memory model is
>
defined. In Java, the memory model is defined enough so that you know
>
that
>
these kinds of operations will work only under very specific conditions
>
(you
>
explictly code a memory sync around your contentious code).
>
>
In other languages like C (and presumably Obj-C), you get the memory model
>
of the underlying CPU.
>
>
You can find Java related information on that kind of problem on bill
>
pugh's
>
website: http://www.cs.umd.edu/~pugh/java/memoryModel/.
>
>
Hope that helps,
>
Vic
>
>
>
On 2002/08/14 9:10 PM, "Raff" <email@hidden> wrote:
>
>
> Sorry to come back about this topic, but I was on holliday;
>
>
>
> about the positive/negative test
>
> if (newObject == object) return;
>
> or
>
> if (newObject != object) {
>
> doIt !
>
> }
>
>
>
> I read it depended on the type of processors.
>
>
>
> I thought it would depend on the compilator : as far as I'm concerned, I
>
> would think the first method is faster because the code produced would
>
> be a test which leads to 'blr'.
>
>
>
> How can it be different on a different machine if I do use the same
>
> compiler ? (sorry if this is a silly question)
>
>
>
> ***
>
>
>
> By the way, is there a program to de-compile code in the developper
>
> utilities ? I didn't find it.
>
> (machine code > PPC/68k assembly language).
>
>
>
> Thanks for your attention.
>
>
>
> R.D.
>
> _______________________________________________
>
> 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.
>
>
--
>
Victor Ng
>
email: email@hidden
>
http://radio.weblogs.com/0108956/
>
_______________________________________________
>
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.
_______________________________________________
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.