On 3/9/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > > From: Leon Rosenberg [mailto:[EMAIL PROTECTED] > > Subject: Re: Performance tricks with multiple tomcat instances > > > > 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.... > > Sorry to burst your bubble, but that's simply not true. Even on a > single CPU system, the OS only lets a given thread run for so long > before switching to another. That switching point can occur at any > time, so there's no guarantee that any operation not done under some > form of concurrency control will be atomic. Certainly there is less > chance of thread interactions on a single CPU, but it's by no means > prevented.
Here, found something in google instead of my book shelf: Atomic energy The first OS-level concept that's important to understand is atomicity. An atomic operation cannot be interrupted by another thread. Java does define at least a few atomic operations. In particular, assignment to variables of any type except long or double is atomic. You don't have to worry about a thread preempting a method in the middle of the assignment. In practice, this means that you never have to synchronize a method that does nothing but return the value of (or assign a value to) a boolean or int instance variable. Similarly, a method that did a lot of computation using only local variables and arguments, and which assigned the results of that computation to an instance variable as the last thing it did, would not have to be synchronized. http://www.javaworld.com/javaworld/jw-09-1998/jw-09-threads.html Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
