Leon Rosenberg wrote:
Well, personally I had collywobbles before we've gone on 2 cpu
machines, but it went well. I mean, as long as you are one cpu machine
you can be sure that your threads are never really concurrent and
atomic operations remain atomic (like ++) but in case of 2 cpus you
start to work really concurrent.... *collywobbles* :-)
Your post of a few days ago caught my eye.
Read-modify-write CPU bus operations are only atomic on x86 when the
atomic increment (increment with memory operand) assembly instruction is
prefixed with a special buslock instruction "lock; incr %0" this forces
the CPU to keep control of the memory bus between the read and write
phases, this temporarily blocks another CPU from memory access.
A classic (normal) increment with memory operand does not lock the
memory bus access during the modify phase of the instruction execution,
this allows another CPU/HT to perform a read and see the old value. The
other CPU may also be performing the same operations in what it believes
to also be an atomic modification of that memory location. You can see
the case for a lost write here.
I would hope that JIT compiler engineers would as a minimum implicitly
add the "lock" instruction before all operations on primitive types
declared volatile that are in the platforms native data width (32bit on
i386, 32&64bit on i386_64. 64bit on ia64). This could possibly be
extended to other data width types if host CPU supports atomic
operations on them (I believe x86 does for 8 and 16 bits too). Remember
many other CPUs do not support unaligned memory access, these CPUs may
only support atomic operations at aligned native data widths. But the
java approach (as I heard described in another thread) seems broken to
me, since not all CPUs and JVMs will be able to support the programmers
intentions of atomic access through the use of "volatile int foo;",
"volatile short foo;", "volatile byte foo;" since on some CPUs this can
only be achieved natively with java "int" or "long" types only.
In the C language the type atomic_t was created to express this data
type in a platform portable way. So maybe the JVM specification should
also adopt a new keyword for a specific atomic integer data type and
another one to mark those accesses to that it must be atomic.
private atomicint foo;
atomic foo++;
Chucks comments on the case of assignment I agree with. In the case of
assignment access to the value is atomic with respect to itself (i.e. it
is not possible for concurrent threads to corrupt each others view of
whatever the current value is during concurrent read or write access,
the most common example of understanding this is that a i386 can access
memory in one operation that is 32bit wide, so if you want to write out
a 64bit value you have to make two memory write cycles and this is done
with two assembler instructions, the i386 processor does not provide
any hardware support to make that atomic, so you have to make that
synchronization / lock happen in software there is no 2 ways about
this). What is not said is that having atomic assignment is not useful
on its own, you could argue the point that annihilation of the old value
with a new value is a single operation, single operations are implicitly
atomic, the word atomic is usually added to give additional weight to
the intention of multiple related operations not for simple operations.
In my eyes the raw primitive building blocks of native atomic operations
on limited integer types should be exposed to the application programmer
to make better use of programing operations assisted by silicon, not
limited to but including increment/decrement, compare and set, compare
and increment/decrement, exchange. A nice clean way to do this in java
would be a with class/method that the JIT would replace with optimized
versions, this would keep keyword pollution down that my naive example
above incites. This would be the same sort of optimization and trick
the JIT can do with common classes like String.
Anyway I'm getting further OT now, treat as food for thought.
--
Darryl L. Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
