Volatile means that a thread won't cache the (value of) a variable. So your making sure that every thread sees updates on that variable.
The Volatile keyword DOES NOT provide protection against multiple read/writes from different threads! Synchronization, locks or atomic variables are still needed when this is an issue. Jeroen Brattinga On Wed, 2008-05-14 at 00:07 -0700, Sangjin Lee wrote: > AFAIK, volatile is the most efficient way of doing memory barriers for > variables that are accessed for read and write by multiple threads. > Synchronizations or atomic variables are alternatives, but possibly more > expensive. Also, I believe doing memory barriers is essential for > visibility... IMHO using non-volatile variables in a multi-threaded > situation is living dangerously. > > Regards, > Sangjin > > On Tue, May 13, 2008 at 10:59 PM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> > wrote: > > > Dmirty raised an interesting question in our configuration properties. > > > > We have so many configuration properties - should each propery declared as > > volatile? Would there be more efficient way than doing so? > > > > On Thu, 08 May 2008 16:43:51 +0900, Дмитрий Батрак <[EMAIL PROTECTED]> > > wrote: > > > > As mentioned in API documentation (I'm talking about MINA-1.1.7), > > > IoSession instances are supposed to be thread-safe. But access to > > > variables idleTimeForRead, idleTimeForWrite and idleTimeForBoth in > > > BaseIoSession class is performed without any synchronization. So, it > > > seems that altering the idle time from any thread other than the > > > processor thread isn't guaranteed to be visible by the processor thread. > > > Shouldn't these variables be made volatile, or am I missing some point? > > > > > > Best regards, > > > Dmitry Batrak > > > > > > > -- > > Trustin Lee - Principal Software Engineer, JBoss, Red Hat > > -- > > what we call human nature is actually human habit > > -- > > http://gleamynode.net/ > >
