You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Jeroen Brattinga <je...@gmail.com> on 2008/05/14 16:59:11 UTC
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
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) <tr...@gmail.com>
> 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, Дмитрий Батрак <de...@yapp.ru> 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/
> >
Re: Should all configuration properties be volatile? (Was: Re: Visibility of idle time changes in BaseIoSession)
Posted by Sangjin Lee <sj...@gmail.com>.
On Wed, May 14, 2008 at 7:59 AM, Jeroen Brattinga <
jeroen.brattinga@gmail.com> wrote:
> 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.
I agree. The discussion was about *visibility*, which volatile helps. If
you need proper synchronization, volatile is not necessarily a substitute.
Thanks,
Sangjin
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
On Thu, 15 May 2008 01:20:37 +0900, Emmanuel Lecharny
<el...@apache.org> wrote:
> 이희승 (Trustin Lee) wrote:
>> What I can tell at least though is that the session configuration
>> properties provided by IoService should be volatile, because they are
>> accessed in a different thread (I/O processor) almost always.
> Use synchronization, not volatile. it's too dangerous. When we are sure
> that it works fine, we _may_ switch to volatile.
We already know all configuration properties are OK with volatile because
what we do with them is just a simple assignment. Synchronization is
safe, but it's way too much in this case.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
It's better than never. :)
On Fri, 16 May 2008 05:44:23 +0900, Pauls, Karl <kp...@trigeo.com> wrote:
> Sorry for being a little late on this, but for behavior-changing
> attributes one technique which I have practiced is to make all fields
> final and when changes are needed I swap out the implementation since my
> enclosing system is thread-safe.
>
> For example, the filter and protocol chains are thread-safe and allow
> adding and removing (and replacing?) filters & protocols in a
> thread-safe manner.
>
> This is a very heavyweight technique for variables which change
> frequently, but in my systems it performs quite well and provides
> explicit transactional behavior when a change is needed.
>
> I don't mind feedback on this idea and I will certainly understand if
> you find this approach is not applicable to MINA. ;)
>
> -karl
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
RE: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "Pauls, Karl" <kp...@trigeo.com>.
Sorry for being a little late on this, but for behavior-changing attributes one technique which I have practiced is to make all fields final and when changes are needed I swap out the implementation since my enclosing system is thread-safe.
For example, the filter and protocol chains are thread-safe and allow adding and removing (and replacing?) filters & protocols in a thread-safe manner.
This is a very heavyweight technique for variables which change frequently, but in my systems it performs quite well and provides explicit transactional behavior when a change is needed.
I don't mind feedback on this idea and I will certainly understand if you find this approach is not applicable to MINA. ;)
-karl
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
이희승 (Trustin Lee) wrote:
> On Thu, 15 May 2008 16:47:32 +0900, Emmanuel Lecharny
> <el...@apache.org> wrote:
>
>> 이희승 (Trustin Lee) wrote:
>>>
>>> The problem is we have so many properties which needs visibility
>>> independent from each other.
>> Do we have a list of all the properties we need to protect? This
>> could be a good start to discuss about the best mechanism to use to
>> protect them.
>>> If we are going to use a lock, we will need as many lock objects as
>>> the number of the properties, which is way too much IMO.
>> You can also synchronize the get() and set() methods, and you don't
>> need a lock anymore. Actually, this might be even more performant
>> than using volatile, if the property is read many times.
>
> using synchronized modifier for a method is same with synchronized
> (this) {...}, and it means all properties of one object will share one
> single lock and cause serious contention.
Fair enough. In this case, in order to protect the property, AtomicXXX
is the best solution for simple types (what a burden to create a lock to
protect an int or a long ... !). If we have access to imutable data
(like String), we don't care about synchronization, as the data are
immutable. For any other data structure, we can do a synchronize(data)
inside the get() and set() (and any other methods), so no need to use a
dedicated lock.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
On Thu, 15 May 2008 16:47:32 +0900, Emmanuel Lecharny
<el...@apache.org> wrote:
> 이희승 (Trustin Lee) wrote:
>>
>> The problem is we have so many properties which needs visibility
>> independent from each other.
> Do we have a list of all the properties we need to protect? This could
> be a good start to discuss about the best mechanism to use to protect
> them.
>> If we are going to use a lock, we will need as many lock objects as the
>> number of the properties, which is way too much IMO.
> You can also synchronize the get() and set() methods, and you don't need
> a lock anymore. Actually, this might be even more performant than using
> volatile, if the property is read many times.
using synchronized modifier for a method is same with synchronized (this)
{...}, and it means all properties of one object will share one single
lock and cause serious contention.
>> Or.. should we just return AtomicXYZ objects for all properties?
> It will depend on the kind of property you want to protect.
>>> public void increaseReadBytes(int increment) {
>>> if (increment > 0) {
>>> readBytes += increment;
>>> lastReadTime = System.currentTimeMillis();
>>> idleCountForBoth = 0;
>>> idleCountForRead = 0;
>>> }
>>> }
>>
>> readBytes += increment; should be atomic, and each assignment
>> operations should be visible to other threads (i.e. volatile is enough).
> In this case, readBytes should be an AtomicInteger then, and you should
> not be able to do a readBytes += increment. Volatile don't protect
> against this operation (if you have a look at the way AtomicInteger is
> written, it's really interesting to find that the stored value is
> volatile, but that the increment operation calls a native method to
> guarantee the concurrent access protection).
>>
>> We can synchronize the whole operation (i.e. increaseReadBytes), but I
>> guess we won't get practical value from it as long as we don't expose
>> an explicit lock object for users.
> What we want to do is to deliver a correct number of read bytes to the
> user. Using an AtomicInteger for it should be enough.
Yes, that's what I meant. :)
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
이희승 (Trustin Lee) wrote:
>
> The problem is we have so many properties which needs visibility
> independent from each other.
Do we have a list of all the properties we need to protect? This could
be a good start to discuss about the best mechanism to use to protect them.
> If we are going to use a lock, we will need as many lock objects as
> the number of the properties, which is way too much IMO.
You can also synchronize the get() and set() methods, and you don't need
a lock anymore. Actually, this might be even more performant than using
volatile, if the property is read many times.
> Or.. should we just return AtomicXYZ objects for all properties?
It will depend on the kind of property you want to protect.
>> public void increaseReadBytes(int increment) {
>> if (increment > 0) {
>> readBytes += increment;
>> lastReadTime = System.currentTimeMillis();
>> idleCountForBoth = 0;
>> idleCountForRead = 0;
>> }
>> }
>
> readBytes += increment; should be atomic, and each assignment
> operations should be visible to other threads (i.e. volatile is enough).
In this case, readBytes should be an AtomicInteger then, and you should
not be able to do a readBytes += increment. Volatile don't protect
against this operation (if you have a look at the way AtomicInteger is
written, it's really interesting to find that the stored value is
volatile, but that the increment operation calls a native method to
guarantee the concurrent access protection).
>
> We can synchronize the whole operation (i.e. increaseReadBytes), but I
> guess we won't get practical value from it as long as we don't expose
> an explicit lock object for users.
What we want to do is to deliver a correct number of read bytes to the
user. Using an AtomicInteger for it should be enough.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
On Thu, 15 May 2008 16:08:58 +0900, Maarten Bosteels
<mb...@gmail.com> wrote:
> On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee)
> <tr...@gmail.com> wrote:
>> Yes. I was actually talking about the configuration properties which
>> meets
>> the two criteria.
>>
>> Of course, counters, which were originally mentioned by Dmirty, should
>> use
>> AtomicIntegers.
>>
>> So.. basically we were mixing up two kinds of properties in our
>> discussion.
>> To sum up:
>>
>> * Use volatile for simple configuration properties
>> * Use AtomicInteger for other counters (except for performance
>> counters
>> which doesn't need to be accurate)
>>
>> Does this make sense to you guys?
>
> Yes, I think that makes sense. I just think that in general, we have
> to be very careful when using volatile instead of locking.
> For the reasons explained by Brian Goetz in the article mentioned
> below, and also because it might be premature optimization
> (or even no optimization at all).
The problem is we have so many properties which needs visibility
independent from each other. If we are going to use a lock, we will need
as many lock objects as the number of the properties, which is way too
much IMO. Or.. should we just return AtomicXYZ objects for all
properties? That's also a problem in terms of memory consumption and
encapsulation. Actually we might need some experiment here.
> When I see a method like below, I wonder if that should be an atomic
> operation ?
> It's probably not really necessary, I don't know the code well enough to
> judge.
>
> public void increaseReadBytes(int increment) {
> if (increment > 0) {
> readBytes += increment;
> lastReadTime = System.currentTimeMillis();
> idleCountForBoth = 0;
> idleCountForRead = 0;
> }
> }
readBytes += increment; should be atomic, and each assignment operations
should be visible to other threads (i.e. volatile is enough).
We can synchronize the whole operation (i.e. increaseReadBytes), but I
guess we won't get practical value from it as long as we don't expose an
explicit lock object for users.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Should all configuration properties be volatile? (Was: Re: Visibility of idle time changes in BaseIoSession)
Posted by Maarten Bosteels <mb...@gmail.com>.
On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee) <tr...@gmail.com> wrote:
> Yes. I was actually talking about the configuration properties which meets
> the two criteria.
>
> Of course, counters, which were originally mentioned by Dmirty, should use
> AtomicIntegers.
>
> So.. basically we were mixing up two kinds of properties in our discussion.
> To sum up:
>
> * Use volatile for simple configuration properties
> * Use AtomicInteger for other counters (except for performance counters
> which doesn't need to be accurate)
>
> Does this make sense to you guys?
Yes, I think that makes sense. I just think that in general, we have
to be very careful when using volatile instead of locking.
For the reasons explained by Brian Goetz in the article mentioned
below, and also because it might be premature optimization
(or even no optimization at all).
When I see a method like below, I wonder if that should be an atomic operation ?
It's probably not really necessary, I don't know the code well enough to judge.
public void increaseReadBytes(int increment) {
if (increment > 0) {
readBytes += increment;
lastReadTime = System.currentTimeMillis();
idleCountForBoth = 0;
idleCountForRead = 0;
}
}
Maarten
>
>
>
> On Thu, 15 May 2008 03:08:58 +0900, Maarten Bosteels
> <mb...@gmail.com> wrote:
>
>
> > Hello,
> >
> > Brian Goetz [1] writes:
> >
> > "You can use volatile variables instead of locks only under a
> > restricted set of circumstances. Both of the following criteria must
> > be met for volatile variables to provide the desired thread-safety:
> >
> > * Writes to the variable do not depend on its current value.
> > * The variable does not participate in invariants with other variables.
> > ...
> > However, if you can arrange that the value is only ever written from a
> > single thread, then you can ignore the first condition.)"
> >
> > But at line 445 of BaseIoSession.java I see:
> >
> > idleCountForRead++;
> >
> > (in a public method called increaseIdleCount so I don't think we can
> > guarantee that only one thread will ever call it)
> >
> > So it's pretty obvious to me that volatile IS NOT good enough if you
> > want a thread-safe solution.
> >
> > [1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
> > [2]
> http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445
> >
> > regards,
> > Maarten
> >
> > On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd <da...@redhat.com>
> wrote:
> >
> > > On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
> > >
> > > >
> > > > David M. Lloyd wrote:
> > > >
> > > > >
> > > > > On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
> > > > >
> > > > > >
> > > > > > David M. Lloyd wrote:
> > > > > >
> > > > > > >
> > > > > > > On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > What I can tell at least though is that the session
> configuration
> > > > > > > > > properties provided by IoService should be volatile, because
> they are
> > > > > > > > > accessed in a different thread (I/O processor) almost
> always.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Use synchronization, not volatile. it's too dangerous. When we
> are
> > > > > > > > sure that it works fine, we _may_ switch to volatile.
> > > > > > > >
> > > > > > >
> > > > > > > I don't understand this? Volatile isn't dangerous at all. It's
> > > > > > > clearly defined and well-specified, and using it to make fields
> have
> > > > > > > multi-thread visibility is a perfectly fine usage for them.
> > > > > > >
> > > > > >
> > > > > > The problem is not that volatile is dangerous by itself. Its
> semantic is
> > > > > > really clear, assuming that you _know_ what you can and can't do.
> This is
> > > > > > what scared me : mis-used of volatile.
> > > > > >
> > > > > > Before of using it, I would rather prefer that we expose the clear
> > > > > > benefits we will get from it (and please, bring the numbers with
> you ;)
> > > > > > before using it all over the code.
> > > > > >
> > > > >
> > > > > Well, if you don't use it, then when someone calls a setter on the
> > > > > property, the change may not be propagated to any other threads,
> meaning
> > > > > that different threads could read different values for those
> properties. If
> > > > > you do add volatile, then this doesn't happen - a change in one
> thread is
> > > > > visible immediately thereafter from another thread.
> > > > >
> > > >
> > > > Synchronise the access to this property.
> > > >
> > >
> > > Why? Synchronization is not needed.
> > >
> > >
> > > > Synchronized getter and setter should be ok. Of course, you may have
> to
> > > > copy the property before sending it to the user. Using volatile does
> not
> > > > protect more than synchronize, so I see no reason to use it in this
> case.
> > > >
> > >
> > > The values don't need more protection.
> > >
> > >
> > > > You will have the very same problem in both case, except that volatile
> is
> > > > only meant to protect the visibility.
> > > >
> > >
> > > Visibility is the only problem here that needs to be solved.
> > >
> > >
> > >
> > > > The fact that volatile does not guarantee atomicity is enough a risk
> to
> > > > justify my assertion.
> > > >
> > >
> > > I don't understand. Atomicity is not a requirement here! The only
> > > requirement is that when the values are changed, the changes are
> immediately
> > > visible to other threads. Volatile solves this issue, and in fact was
> > > designed for this. What additional semantics does synchronization
> provide
> > > that are not solved by volatile?
> > >
> > >
> > > > The 'performance' word was used in Trustin's answer to Dmitry mail. If
> it
> > > > does not work, then first synchronize the code in order to make it
> thread
> > > > safe. Volatile is just a weaker way to 'fix the code', not a solution.
> > > >
> > > > Dmitry first mail was about the problem he founds, and he suggested to
> use
> > > > volatile. I suggest we don't and that we synchronize first, until we
> have
> > > > fixed the problem.
> > > >
> > >
> > > This makes no sense. Fear is not a reason to use or not use something.
> The
> > > problem is the lack of visibility, and the solution is volatile.
> > >
> > > - DML
> > >
> > >
> >
>
>
>
>
> --
> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
David M. Lloyd wrote:
> In the case for that field, an AtomicInteger is clearly called for.
Absolutely. And the authors mention it.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by "David M. Lloyd" <da...@redhat.com>.
In the case for that field, an AtomicInteger is clearly called for.
- DML
On 05/14/2008 01:08 PM, Maarten Bosteels wrote:
> Hello,
>
> Brian Goetz [1] writes:
>
> "You can use volatile variables instead of locks only under a
> restricted set of circumstances. Both of the following criteria must
> be met for volatile variables to provide the desired thread-safety:
>
> * Writes to the variable do not depend on its current value.
> * The variable does not participate in invariants with other variables.
> ...
> However, if you can arrange that the value is only ever written from a
> single thread, then you can ignore the first condition.)"
>
> But at line 445 of BaseIoSession.java I see:
>
> idleCountForRead++;
>
> (in a public method called increaseIdleCount so I don't think we can
> guarantee that only one thread will ever call it)
>
> So it's pretty obvious to me that volatile IS NOT good enough if you
> want a thread-safe solution.
>
> [1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
> [2] http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445
>
> regards,
> Maarten
>
> On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd <da...@redhat.com> wrote:
>> On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
>>> David M. Lloyd wrote:
>>>> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
>>>>> David M. Lloyd wrote:
>>>>>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>>>>>
>>>>>>>> What I can tell at least though is that the session configuration
>>>>>>>> properties provided by IoService should be volatile, because they are
>>>>>>>> accessed in a different thread (I/O processor) almost always.
>>>>>>> Use synchronization, not volatile. it's too dangerous. When we are
>>>>>>> sure that it works fine, we _may_ switch to volatile.
>>>>>> I don't understand this? Volatile isn't dangerous at all. It's
>>>>>> clearly defined and well-specified, and using it to make fields have
>>>>>> multi-thread visibility is a perfectly fine usage for them.
>>>>> The problem is not that volatile is dangerous by itself. Its semantic is
>>>>> really clear, assuming that you _know_ what you can and can't do. This is
>>>>> what scared me : mis-used of volatile.
>>>>>
>>>>> Before of using it, I would rather prefer that we expose the clear
>>>>> benefits we will get from it (and please, bring the numbers with you ;)
>>>>> before using it all over the code.
>>>> Well, if you don't use it, then when someone calls a setter on the
>>>> property, the change may not be propagated to any other threads, meaning
>>>> that different threads could read different values for those properties. If
>>>> you do add volatile, then this doesn't happen - a change in one thread is
>>>> visible immediately thereafter from another thread.
>>> Synchronise the access to this property.
>> Why? Synchronization is not needed.
>>
>>> Synchronized getter and setter should be ok. Of course, you may have to
>>> copy the property before sending it to the user. Using volatile does not
>>> protect more than synchronize, so I see no reason to use it in this case.
>> The values don't need more protection.
>>
>>> You will have the very same problem in both case, except that volatile is
>>> only meant to protect the visibility.
>> Visibility is the only problem here that needs to be solved.
>>
>>
>>> The fact that volatile does not guarantee atomicity is enough a risk to
>>> justify my assertion.
>> I don't understand. Atomicity is not a requirement here! The only
>> requirement is that when the values are changed, the changes are immediately
>> visible to other threads. Volatile solves this issue, and in fact was
>> designed for this. What additional semantics does synchronization provide
>> that are not solved by volatile?
>>
>>> The 'performance' word was used in Trustin's answer to Dmitry mail. If it
>>> does not work, then first synchronize the code in order to make it thread
>>> safe. Volatile is just a weaker way to 'fix the code', not a solution.
>>>
>>> Dmitry first mail was about the problem he founds, and he suggested to use
>>> volatile. I suggest we don't and that we synchronize first, until we have
>>> fixed the problem.
>> This makes no sense. Fear is not a reason to use or not use something. The
>> problem is the lack of visibility, and the solution is volatile.
>>
>> - DML
>>
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
Yes. I was actually talking about the configuration properties which
meets the two criteria.
Of course, counters, which were originally mentioned by Dmirty, should use
AtomicIntegers.
So.. basically we were mixing up two kinds of properties in our
discussion. To sum up:
* Use volatile for simple configuration properties
* Use AtomicInteger for other counters (except for performance counters
which doesn't need to be accurate)
Does this make sense to you guys?
On Thu, 15 May 2008 03:08:58 +0900, Maarten Bosteels
<mb...@gmail.com> wrote:
> Hello,
>
> Brian Goetz [1] writes:
>
> "You can use volatile variables instead of locks only under a
> restricted set of circumstances. Both of the following criteria must
> be met for volatile variables to provide the desired thread-safety:
>
> * Writes to the variable do not depend on its current value.
> * The variable does not participate in invariants with other
> variables.
> ...
> However, if you can arrange that the value is only ever written from a
> single thread, then you can ignore the first condition.)"
>
> But at line 445 of BaseIoSession.java I see:
>
> idleCountForRead++;
>
> (in a public method called increaseIdleCount so I don't think we can
> guarantee that only one thread will ever call it)
>
> So it's pretty obvious to me that volatile IS NOT good enough if you
> want a thread-safe solution.
>
> [1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
> [2]
> http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445
>
> regards,
> Maarten
>
> On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd <da...@redhat.com>
> wrote:
>> On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
>>>
>>> David M. Lloyd wrote:
>>>>
>>>> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>> David M. Lloyd wrote:
>>>>>>
>>>>>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>>>>>
>>>>>>>> What I can tell at least though is that the session configuration
>>>>>>>> properties provided by IoService should be volatile, because they
>>>>>>>> are
>>>>>>>> accessed in a different thread (I/O processor) almost always.
>>>>>>>
>>>>>>> Use synchronization, not volatile. it's too dangerous. When we are
>>>>>>> sure that it works fine, we _may_ switch to volatile.
>>>>>>
>>>>>> I don't understand this? Volatile isn't dangerous at all. It's
>>>>>> clearly defined and well-specified, and using it to make fields have
>>>>>> multi-thread visibility is a perfectly fine usage for them.
>>>>>
>>>>> The problem is not that volatile is dangerous by itself. Its
>>>>> semantic is
>>>>> really clear, assuming that you _know_ what you can and can't do.
>>>>> This is
>>>>> what scared me : mis-used of volatile.
>>>>>
>>>>> Before of using it, I would rather prefer that we expose the clear
>>>>> benefits we will get from it (and please, bring the numbers with you
>>>>> ;)
>>>>> before using it all over the code.
>>>>
>>>> Well, if you don't use it, then when someone calls a setter on the
>>>> property, the change may not be propagated to any other threads,
>>>> meaning
>>>> that different threads could read different values for those
>>>> properties. If
>>>> you do add volatile, then this doesn't happen - a change in one
>>>> thread is
>>>> visible immediately thereafter from another thread.
>>>
>>> Synchronise the access to this property.
>>
>> Why? Synchronization is not needed.
>>
>>> Synchronized getter and setter should be ok. Of course, you may have to
>>> copy the property before sending it to the user. Using volatile does
>>> not
>>> protect more than synchronize, so I see no reason to use it in this
>>> case.
>>
>> The values don't need more protection.
>>
>>> You will have the very same problem in both case, except that volatile
>>> is
>>> only meant to protect the visibility.
>>
>> Visibility is the only problem here that needs to be solved.
>>
>>
>>> The fact that volatile does not guarantee atomicity is enough a risk to
>>> justify my assertion.
>>
>> I don't understand. Atomicity is not a requirement here! The only
>> requirement is that when the values are changed, the changes are
>> immediately
>> visible to other threads. Volatile solves this issue, and in fact was
>> designed for this. What additional semantics does synchronization
>> provide
>> that are not solved by volatile?
>>
>>> The 'performance' word was used in Trustin's answer to Dmitry mail. If
>>> it
>>> does not work, then first synchronize the code in order to make it
>>> thread
>>> safe. Volatile is just a weaker way to 'fix the code', not a solution.
>>>
>>> Dmitry first mail was about the problem he founds, and he suggested to
>>> use
>>> volatile. I suggest we don't and that we synchronize first, until we
>>> have
>>> fixed the problem.
>>
>> This makes no sense. Fear is not a reason to use or not use something.
>> The
>> problem is the lack of visibility, and the solution is volatile.
>>
>> - DML
>>
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
Maarten Bosteels wrote:
> Hello,
>
> Brian Goetz [1] writes:
>
> "You can use volatile variables instead of locks only under a
> restricted set of circumstances. Both of the following criteria must
> be met for volatile variables to provide the desired thread-safety:
>
> * Writes to the variable do not depend on its current value.
> * The variable does not participate in invariants with other variables.
> ...
> However, if you can arrange that the value is only ever written from a
> single thread, then you can ignore the first condition.)"
>
> But at line 445 of BaseIoSession.java I see:
>
> idleCountForRead++;
>
> (in a public method called increaseIdleCount so I don't think we can
> guarantee that only one thread will ever call it)
>
> So it's pretty obvious to me that volatile IS NOT good enough if you
> want a thread-safe solution.
>
Exactly. Thanks Marteen.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re: Visibility of idle time changes in BaseIoSession)
Posted by Maarten Bosteels <mb...@gmail.com>.
Hello,
Brian Goetz [1] writes:
"You can use volatile variables instead of locks only under a
restricted set of circumstances. Both of the following criteria must
be met for volatile variables to provide the desired thread-safety:
* Writes to the variable do not depend on its current value.
* The variable does not participate in invariants with other variables.
...
However, if you can arrange that the value is only ever written from a
single thread, then you can ignore the first condition.)"
But at line 445 of BaseIoSession.java I see:
idleCountForRead++;
(in a public method called increaseIdleCount so I don't think we can
guarantee that only one thread will ever call it)
So it's pretty obvious to me that volatile IS NOT good enough if you
want a thread-safe solution.
[1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
[2] http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445
regards,
Maarten
On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd <da...@redhat.com> wrote:
> On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
>>
>> David M. Lloyd wrote:
>>>
>>> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
>>>>
>>>> David M. Lloyd wrote:
>>>>>
>>>>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>>>>
>>>>>>> What I can tell at least though is that the session configuration
>>>>>>> properties provided by IoService should be volatile, because they are
>>>>>>> accessed in a different thread (I/O processor) almost always.
>>>>>>
>>>>>> Use synchronization, not volatile. it's too dangerous. When we are
>>>>>> sure that it works fine, we _may_ switch to volatile.
>>>>>
>>>>> I don't understand this? Volatile isn't dangerous at all. It's
>>>>> clearly defined and well-specified, and using it to make fields have
>>>>> multi-thread visibility is a perfectly fine usage for them.
>>>>
>>>> The problem is not that volatile is dangerous by itself. Its semantic is
>>>> really clear, assuming that you _know_ what you can and can't do. This is
>>>> what scared me : mis-used of volatile.
>>>>
>>>> Before of using it, I would rather prefer that we expose the clear
>>>> benefits we will get from it (and please, bring the numbers with you ;)
>>>> before using it all over the code.
>>>
>>> Well, if you don't use it, then when someone calls a setter on the
>>> property, the change may not be propagated to any other threads, meaning
>>> that different threads could read different values for those properties. If
>>> you do add volatile, then this doesn't happen - a change in one thread is
>>> visible immediately thereafter from another thread.
>>
>> Synchronise the access to this property.
>
> Why? Synchronization is not needed.
>
>> Synchronized getter and setter should be ok. Of course, you may have to
>> copy the property before sending it to the user. Using volatile does not
>> protect more than synchronize, so I see no reason to use it in this case.
>
> The values don't need more protection.
>
>> You will have the very same problem in both case, except that volatile is
>> only meant to protect the visibility.
>
> Visibility is the only problem here that needs to be solved.
>
>
>> The fact that volatile does not guarantee atomicity is enough a risk to
>> justify my assertion.
>
> I don't understand. Atomicity is not a requirement here! The only
> requirement is that when the values are changed, the changes are immediately
> visible to other threads. Volatile solves this issue, and in fact was
> designed for this. What additional semantics does synchronization provide
> that are not solved by volatile?
>
>> The 'performance' word was used in Trustin's answer to Dmitry mail. If it
>> does not work, then first synchronize the code in order to make it thread
>> safe. Volatile is just a weaker way to 'fix the code', not a solution.
>>
>> Dmitry first mail was about the problem he founds, and he suggested to use
>> volatile. I suggest we don't and that we synchronize first, until we have
>> fixed the problem.
>
> This makes no sense. Fear is not a reason to use or not use something. The
> problem is the lack of visibility, and the solution is volatile.
>
> - DML
>
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by Jeroen Brattinga <je...@gmail.com>.
This page is pretty clear on this subject:
http://www.ibm.com/developerworks/java/library/j-praxis/pr50.html
In short: "If concurrency is important and you are not updating many
variables, consider using volatile. If you are updating many variables,
however, using volatile might be slower than using synchronization."
Jeroen Brattinga
On Wed, 2008-05-14 at 12:05 -0500, David M. Lloyd wrote:
> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
> > David M. Lloyd wrote:
> >> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
> >>
> >>>> What I can tell at least though is that the session configuration
> >>>> properties provided by IoService should be volatile, because they
> >>>> are accessed in a different thread (I/O processor) almost always.
> >>> Use synchronization, not volatile. it's too dangerous. When we are
> >>> sure that it works fine, we _may_ switch to volatile.
> >>
> >> I don't understand this? Volatile isn't dangerous at all. It's
> >> clearly defined and well-specified, and using it to make fields have
> >> multi-thread visibility is a perfectly fine usage for them.
> > The problem is not that volatile is dangerous by itself. Its semantic is
> > really clear, assuming that you _know_ what you can and can't do. This
> > is what scared me : mis-used of volatile.
> >
> > Before of using it, I would rather prefer that we expose the clear
> > benefits we will get from it (and please, bring the numbers with you ;)
> > before using it all over the code.
>
> Well, if you don't use it, then when someone calls a setter on the
> property, the change may not be propagated to any other threads, meaning
> that different threads could read different values for those properties.
> If you do add volatile, then this doesn't happen - a change in one thread
> is visible immediately thereafter from another thread.
>
> If you're suggesting that volatile isn't the appropriate solution to this
> problem, I say that the burden is on you to explain why using the correct
> tool for the job is not acceptable in this case, and what you hope to solve
> (and be specific, FUD like "I'm afraid it will be misused" isn't good
> enough) by using something more complex. We're talking about fields that
> are accessed via simple getter and setter methods here.
>
> Again, you're saying "volatile is too dangerous", but you're not really
> giving any specific reasons for this odd statement.
>
> > We are talking about minor improvement in this area. We have much bigger
> > issues and much more important thinsg to deal with in MINA 2.0.
>
> Minor improvement? I thought we were talking about taking something that
> doesn't work, and fixing it.
>
> - DML
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by "David M. Lloyd" <da...@redhat.com>.
On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
> David M. Lloyd wrote:
>> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
>>> David M. Lloyd wrote:
>>>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>>>
>>>>>> What I can tell at least though is that the session configuration
>>>>>> properties provided by IoService should be volatile, because they
>>>>>> are accessed in a different thread (I/O processor) almost always.
>>>>> Use synchronization, not volatile. it's too dangerous. When we are
>>>>> sure that it works fine, we _may_ switch to volatile.
>>>>
>>>> I don't understand this? Volatile isn't dangerous at all. It's
>>>> clearly defined and well-specified, and using it to make fields have
>>>> multi-thread visibility is a perfectly fine usage for them.
>>> The problem is not that volatile is dangerous by itself. Its semantic
>>> is really clear, assuming that you _know_ what you can and can't do.
>>> This is what scared me : mis-used of volatile.
>>>
>>> Before of using it, I would rather prefer that we expose the clear
>>> benefits we will get from it (and please, bring the numbers with you
>>> ;) before using it all over the code.
>>
>> Well, if you don't use it, then when someone calls a setter on the
>> property, the change may not be propagated to any other threads,
>> meaning that different threads could read different values for those
>> properties. If you do add volatile, then this doesn't happen - a
>> change in one thread is visible immediately thereafter from another
>> thread.
> Synchronise the access to this property.
Why? Synchronization is not needed.
> Synchronized getter and setter should be ok. Of course, you may have to
> copy the property before sending it to the user. Using volatile does not
> protect more than synchronize, so I see no reason to use it in this
> case.
The values don't need more protection.
> You will have the very same problem in both case, except that
> volatile is only meant to protect the visibility.
Visibility is the only problem here that needs to be solved.
> The fact that volatile does not guarantee atomicity is enough a risk to justify my
> assertion.
I don't understand. Atomicity is not a requirement here! The only
requirement is that when the values are changed, the changes are
immediately visible to other threads. Volatile solves this issue, and in
fact was designed for this. What additional semantics does synchronization
provide that are not solved by volatile?
> The 'performance' word was used in Trustin's answer to Dmitry mail. If
> it does not work, then first synchronize the code in order to make it
> thread safe. Volatile is just a weaker way to 'fix the code', not a
> solution.
>
> Dmitry first mail was about the problem he founds, and he suggested to
> use volatile. I suggest we don't and that we synchronize first, until we
> have fixed the problem.
This makes no sense. Fear is not a reason to use or not use something.
The problem is the lack of visibility, and the solution is volatile.
- DML
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
David M. Lloyd wrote:
> On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
>> David M. Lloyd wrote:
>>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>>
>>>>> What I can tell at least though is that the session configuration
>>>>> properties provided by IoService should be volatile, because they
>>>>> are accessed in a different thread (I/O processor) almost always.
>>>> Use synchronization, not volatile. it's too dangerous. When we are
>>>> sure that it works fine, we _may_ switch to volatile.
>>>
>>> I don't understand this? Volatile isn't dangerous at all. It's
>>> clearly defined and well-specified, and using it to make fields have
>>> multi-thread visibility is a perfectly fine usage for them.
>> The problem is not that volatile is dangerous by itself. Its semantic
>> is really clear, assuming that you _know_ what you can and can't do.
>> This is what scared me : mis-used of volatile.
>>
>> Before of using it, I would rather prefer that we expose the clear
>> benefits we will get from it (and please, bring the numbers with you
>> ;) before using it all over the code.
>
> Well, if you don't use it, then when someone calls a setter on the
> property, the change may not be propagated to any other threads,
> meaning that different threads could read different values for those
> properties. If you do add volatile, then this doesn't happen - a
> change in one thread is visible immediately thereafter from another
> thread.
Synchronise the access to this property.
>
> If you're suggesting that volatile isn't the appropriate solution to
> this problem, I say that the burden is on you to explain why using the
> correct tool for the job is not acceptable in this case, and what you
> hope to solve (and be specific, FUD like "I'm afraid it will be
> misused" isn't good enough) by using something more complex. We're
> talking about fields that are accessed via simple getter and setter
> methods here.
Synchronized getter and setter should be ok. Of course, you may have to
copy the property before sending it to the user. Using volatile does not
protect more than synchronize, so I see no reason to use it in this
case. You will have the very same problem in both case, except that
volatile is only meant to protect the visibility.
>
>
> Again, you're saying "volatile is too dangerous", but you're not
> really giving any specific reasons for this odd statement.
Ignorance is dangerous. People don't know about volatile. You can just
check by reading this thread. I don't expect people to magically know
everything about everything, simply because we want to (not to mention
that I'm a member of the 'people' group, of course ;). The fact that
volatile does not guarantee atomicity is enough a risk to justify my
assertion.
>
>> We are talking about minor improvement in this area. We have much
>> bigger issues and much more important thinsg to deal with in MINA 2.0.
>
> Minor improvement? I thought we were talking about taking something
> that doesn't work, and fixing it.
The 'performance' word was used in Trustin's answer to Dmitry mail. If
it does not work, then first synchronize the code in order to make it
thread safe. Volatile is just a weaker way to 'fix the code', not a
solution.
Dmitry first mail was about the problem he founds, and he suggested to
use volatile. I suggest we don't and that we synchronize first, until we
have fixed the problem.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by "David M. Lloyd" <da...@redhat.com>.
On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:
> David M. Lloyd wrote:
>> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>>
>>>> What I can tell at least though is that the session configuration
>>>> properties provided by IoService should be volatile, because they
>>>> are accessed in a different thread (I/O processor) almost always.
>>> Use synchronization, not volatile. it's too dangerous. When we are
>>> sure that it works fine, we _may_ switch to volatile.
>>
>> I don't understand this? Volatile isn't dangerous at all. It's
>> clearly defined and well-specified, and using it to make fields have
>> multi-thread visibility is a perfectly fine usage for them.
> The problem is not that volatile is dangerous by itself. Its semantic is
> really clear, assuming that you _know_ what you can and can't do. This
> is what scared me : mis-used of volatile.
>
> Before of using it, I would rather prefer that we expose the clear
> benefits we will get from it (and please, bring the numbers with you ;)
> before using it all over the code.
Well, if you don't use it, then when someone calls a setter on the
property, the change may not be propagated to any other threads, meaning
that different threads could read different values for those properties.
If you do add volatile, then this doesn't happen - a change in one thread
is visible immediately thereafter from another thread.
If you're suggesting that volatile isn't the appropriate solution to this
problem, I say that the burden is on you to explain why using the correct
tool for the job is not acceptable in this case, and what you hope to solve
(and be specific, FUD like "I'm afraid it will be misused" isn't good
enough) by using something more complex. We're talking about fields that
are accessed via simple getter and setter methods here.
Again, you're saying "volatile is too dangerous", but you're not really
giving any specific reasons for this odd statement.
> We are talking about minor improvement in this area. We have much bigger
> issues and much more important thinsg to deal with in MINA 2.0.
Minor improvement? I thought we were talking about taking something that
doesn't work, and fixing it.
- DML
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
David M. Lloyd wrote:
> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>
>>> What I can tell at least though is that the session configuration
>>> properties provided by IoService should be volatile, because they
>>> are accessed in a different thread (I/O processor) almost always.
>> Use synchronization, not volatile. it's too dangerous. When we are
>> sure that it works fine, we _may_ switch to volatile.
>
> I don't understand this? Volatile isn't dangerous at all. It's
> clearly defined and well-specified, and using it to make fields have
> multi-thread visibility is a perfectly fine usage for them.
The problem is not that volatile is dangerous by itself. Its semantic is
really clear, assuming that you _know_ what you can and can't do. This
is what scared me : mis-used of volatile.
Before of using it, I would rather prefer that we expose the clear
benefits we will get from it (and please, bring the numbers with you ;)
before using it all over the code.
We are talking about minor improvement in this area. We have much bigger
issues and much more important thinsg to deal with in MINA 2.0.
When MINA 2.0 will be out, code tested, performance checked, javadoc
written, unit tests added, user documentation updated, issues fixed,
then we may have fun playing with bits and nanoseconds. Until then...
Thanks !
>
> - DML
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by "David M. Lloyd" <da...@redhat.com>.
On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
>> What I can tell at least though is that the session configuration
>> properties provided by IoService should be volatile, because they are
>> accessed in a different thread (I/O processor) almost always.
> Use synchronization, not volatile. it's too dangerous. When we are sure
> that it works fine, we _may_ switch to volatile.
I don't understand this? Volatile isn't dangerous at all. It's clearly
defined and well-specified, and using it to make fields have multi-thread
visibility is a perfectly fine usage for them.
- DML
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
이희승 (Trustin Lee) wrote:
> Well, don't we need to think about this issue from the MINA standpoint?
I don't see that as an issue, as far as the properties are protexted
with correct synchronization.
> MINA is a framework / library and is considereed to be thread-safe in
> most cases, especially classes related with IoSession should be.
Yep, and it should be well protected. Synchonization is bullet proof.
Volatile is really weak, at least in a framework, as it does not protect
the users who don't understand the contract.
>
> What Dmirty pointed out is that there's a potential visibility problem
> in some of our configuration properties (including some performance
> counters?)
We have to add some synchronization, then. Can be costly, but nothing
comes at no price those days ;)
>
> I don't think all properties should be exposed that precisely
> (especially the statistical stuff).
Anyway, 74,7% of all the statistics are proven to be wrong ...
> Moreover, so far, modification of any configuration properties seems
> to be visible between user threads and I/O processors due to some side
> effect of existing synchronization.
Uh? What does it means?
> However, it is also true that we are depending on a tricky
> optimization which can be fragile. Or it might have been broken
> already and it's just difficult to reproduce.
Yeah, that might be an option.
> We actually don't know the cost of making those properties volatile
> yet, but it is also true that we should value visibility than
> performance built on top of inaccuracy.
We should value correctness. Synchronization guarantee that if correctly
written. Volatile does not. Performance is irrelevant. If you want a
perfomant implementation on top of MINA, then disable the stats.
Watching destroys what is being watched (Schrodinger).
>
> What I can tell at least though is that the session configuration
> properties provided by IoService should be volatile, because they are
> accessed in a different thread (I/O processor) almost always.
Use synchronization, not volatile. it's too dangerous. When we are sure
that it works fine, we _may_ switch to volatile.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Should all configuration properties be volatile? (Was: Re:
Visibility of idle time changes in BaseIoSession)
Posted by "이희승 (Trustin Lee)" <tr...@gmail.com>.
Well, don't we need to think about this issue from the MINA standpoint?
There's already plenty resources related with volatile and synchronized
keyword in the world.
MINA is a framework / library and is considereed to be thread-safe in most
cases, especially classes related with IoSession should be.
What Dmirty pointed out is that there's a potential visibility problem in
some of our configuration properties (including some performance counters?)
I don't think all properties should be exposed that precisely (especially
the statistical stuff). Moreover, so far, modification of any
configuration properties seems to be visible between user threads and I/O
processors due to some side effect of existing synchronization. However,
it is also true that we are depending on a tricky optimization which can
be fragile. Or it might have been broken already and it's just difficult
to reproduce. We actually don't know the cost of making those properties
volatile yet, but it is also true that we should value visibility than
performance built on top of inaccuracy.
What I can tell at least though is that the session configuration
properties provided by IoService should be volatile, because they are
accessed in a different thread (I/O processor) almost always. Please let
us know if there's more.
On Thu, 15 May 2008 00:15:58 +0900, Emmanuel Lecharny
<el...@apache.org> wrote:
> Jeroen Brattinga wrote:
>> 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.
> More precisely, defining a variable as 'volatile' will forbid the JiT
> compiler to optimize the code up to a point the variable is put into a
> registry, but remains a plain java object. This is important because a
> registry is *not* shared with other threads, which is potentially a
> problem when another thread want to modify or read this variable.
>> The Volatile keyword DOES NOT provide protection against multiple
>> read/writes from different threads!
> In fact, it does. But you can only protect the concurrent access for
> simple get and set operations, not for any other kind of operation (like
> i++, for instance, if i is declared as volatile).
>
>> Synchronization, locks or atomic
>> variables are still needed when this is an issue.
>>
>
> In any case, I would suggest we don't use volatile, as it masks some
> semantic. Using a synchronized portion may cost slightly more time, but
> at least, it is explicit, and helps coders to remember what's going on
> with the protected variable.
>
> For those who don't clearly understand the meaning of Volatile, and its
> consequences, I would suggest the perfect book "Java concurrency in
> practice", written by Brian Goetz, especially chapter 3.1.4.
>
>
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Should all configuration properties be volatile? (Was: Re: Visibility
of idle time changes in BaseIoSession)
Posted by Emmanuel Lecharny <el...@apache.org>.
Jeroen Brattinga wrote:
> 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.
>
More precisely, defining a variable as 'volatile' will forbid the JiT
compiler to optimize the code up to a point the variable is put into a
registry, but remains a plain java object. This is important because a
registry is *not* shared with other threads, which is potentially a
problem when another thread want to modify or read this variable.
> The Volatile keyword DOES NOT provide protection against multiple
> read/writes from different threads!
In fact, it does. But you can only protect the concurrent access for
simple get and set operations, not for any other kind of operation (like
i++, for instance, if i is declared as volatile).
> Synchronization, locks or atomic
> variables are still needed when this is an issue.
>
In any case, I would suggest we don't use volatile, as it masks some
semantic. Using a synchronized portion may cost slightly more time, but
at least, it is explicit, and helps coders to remember what's going on
with the protected variable.
For those who don't clearly understand the meaning of Volatile, and its
consequences, I would suggest the perfect book "Java concurrency in
practice", written by Brian Goetz, especially chapter 3.1.4.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org