> From: Darryl L. Miles [mailto:[EMAIL PROTECTED] > Subject: Re: [OT] Performance tricks with multiple tomcat instances > > I had read some comments that might lead others to think > that "count++" on a java "int" type is in some way atomic.
Yes, there are many misinformed people out there, even in the Java community :-) > You miss the goal of programming to the lowest common > denominator with your point, write once run anywhere is > something of value to me Also to me, but my perspective is a bit different. Since I get paid to develop a JIT, I can take advantage of optimizations available on whatever platform I'm targeting, without changing the application's class files. > I don't understand your contradiction "are implicitly atomic - but > there's no guarantee" if there is no guarantee then by my > book it is not atomic. Not from a Java programmer's perspective, but definitely useful from the point of view of a JVM implementor - which is what your original message started out with. > But atomic assignment is like saying the grass is green and > the sky is blue. Not at all - which is why it's explicitly stated in the Java/JVM specs. On platforms where the pointer size is larger than the indivisible data path to memory, it can't be taken for granted. Even on IA32, if your 32-bit address is not on a 4-byte boundary, the update is not atomic; this constrains one from using packed data structures. > There is no useful point to make here, it is a given > that memory load/store operations using native bit > width operations on any CPU are atomic See the above for IA32 on non-32-bit boundaries. (I'm only using IA32 due to its proliferation; there are many other platforms where there's even less provision for atomic updates.) > you are either loading or storing not both. What happens when there are two components (CPUs, IO channels, whatever) updating the same 32 or 64 bits? Any off-boundary write turns into a read-update-write sequence, and that can be interleaved with writes from another component. (I've been working on multiprocessor architectures since the late 1960s - the off-boundary writes are always an issue. When you start throwing 32 CPUs together with hundreds of IO processors, the interactions are always "interesting".) > So yes in the computing world atomic assignment is absolutely > critical but so is register addition. How do you account for machines without registers? The JVM spec defines one such, but real commercial register-less CPUs exist (your bank is probably using one). > Are you saying that there are some CPUs that support > unaligned access to memory (like x86) that do not have > atomic writes to memory. See the Intel architecture specs for an example. This is true of every system I know of. > I was under the impression that such accesses by the CPU > to the memory bus were atomic, because the CPU acquired > the memory bus, then did one or more writes in burst before > releasing the memory bus. Most updates do not go directly on the bus - they are cached (usually multiple levels these days), and are eventually trickled out to the bus as time permits. When a write spans a cache line (or even worse, a page boundary), lots of intervening events can occur. Propagating a bus lock under such conditions would bring the whole system to a halt. > A kernel can not task switch an assembly instruction so under > single CPU the read-modify-write (with or without the LOCK) is > always 100% successful That depends on where the interrupt points within the instruction stream can occur. On highly microcoded CPUs, one could define an interrupt point between the two memory accesses, but most platforms do not, as long as the accesses are within a single cache line. If the accesses span cache lines, an asynchronous interrupt can occur resulting in task switching. > Sorry if this is sucking eggs here. A bit - I've been doing this a long time. > FYI - The Sun documention that headlines the package talks in > terms of "volatile" values. LOL That is quite appropriate. If the data item is not volatile, then atomic operations are not needed, by definition. All synchronized operations within the JVM must follow the rules for volatility, in terms of the external visibility of writes (constrains the out-of-order operations that many RISC systems employ). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
