RE: FW: Java Vs RPG on iSeries -- JAVA400-L

On 09/19/2002 at 05:34:31 PM, java400-l-admin@midrange.com wrote:
what is "hardware" in the java world?  The underlying OS?

also, what is "unordered storage access"?  it sounds bad. does the iSeries
allow such a thing?
--- end of excerpt ---

Yes, OS and actual Hardware.
Don't be tricked into thinking the hardware isn't an issue for Java
programmers in all cases.
In many cases (perhaps most) its not, but in threading and the memory
model, it sometimes
becomes an issue.
For example, scheduling and timing behavior (due to priority and the
scheulding algorithm of the
OS) of your Java threads are greatly effected by the underlying OS.
Some networking behavior probably falls into this category too, I think.


Ok...
I'm opening myself up to errors in the rest of this post. But its for the
good of the group I fall on my sword. 8-)

Unordered storage access is really not that bad, its only an issue for data
shared between threads
(actually processors on the machine I think?) if you hit it, you were
probably doing something illegal
like accessing shared data from two threads without a lock ANYWAY.
This just makes it worse.

So, I'm going to try to be vague (like my understanding). I'm sure I've
probably got some of the
hardware details wrong, but someone else can fill in corrections and we'll
all learn something.

Intro:
When loading/storing data, that data doesn't go between main memory and
register components of the hardware.
Instead, it actually goes between the  main memory <-> level 2 cache <->
possibly a level 3 cache <-> registers
So, lets say you have Java thread 1 which after interpretation or JIT
compilation executes these machine instruction.

Thread 1:
store x.count from reg1
store x.value from reg2
store x from reg3
continue other stuff

The reality is that by the time we're to the 'continue other stuff', the
x.count, x.value and x memory
locations have not been updated. Instead, those values may have been
updated or are in the cache
completely dependant on the hardware, cache size, how full the cache was,
etc...

On a strongly consistent hardware (ordered), x.count is always visible in
memory followed by x.value followed
by x. I.e. if x is updated, its guaranteed that the prior values are.

On a weakly consistent hardware (unordered), there's the additional
possibility that the stores
to main memory are reordered (due to optimization) by the machine.
I.e. x might very well make it into main storage, while x.count and x.value
are still in the cache and
their values not visible.

BUT... All this weirdness only is an issue in multi-threaded programming,
because within a single
thread, the registers/cache are always consistent.

Regardless of hardware, you ALWAYS need a lock (synchronized block) to
ensure that the
machine instructions responsible for flushing data from the registers and
cache to main memory for
that data are executed.







"The stuff we call "software" is not like anything that human society
  is used to thinking about. Software is something like a machine, and
  something like mathematics, and something like language, and
  something like thought, and art, and information...
  but software is not in fact any of those other things."
Bruce Sterling - The Hacker Crackdown

Fred A. Kulack - IBM eServer iSeries - Enterprise Application Solutions
ERP, Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@magnaspeed.net
AIM Home:FKulack  AIM Work:FKulackWrk
MSN Work: fakulack@hotmail.com