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 volatil
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
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 depe
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 fo
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.
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 sh
David M. Lloyd wrote:
On 05/14/2008 12:11 PM, Emmanuel Lecharny wrote:
David M. Lloyd wrote:
On 05/14/2008 10:55 AM, Emmanuel Lecharny wrote:
Sangjin Lee wrote:
Hmm... Could you share a simple example of a non-volatile
variable that
respects the volatile contract?
any boolean.
This i
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
On 05/14/2008 12:11 PM, Emmanuel Lecharny wrote:
David M. Lloyd wrote:
On 05/14/2008 10:55 AM, Emmanuel Lecharny wrote:
Sangjin Lee wrote:
Hmm... Could you share a simple example of a non-volatile variable
that
respects the volatile contract?
any boolean.
This is incorrect. Changes m
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 usi
David M. Lloyd wrote:
On 05/14/2008 10:55 AM, Emmanuel Lecharny wrote:
Sangjin Lee wrote:
Hmm... Could you share a simple example of a non-volatile variable
that
respects the volatile contract?
any boolean.
This is incorrect. Changes made to a boolean that is not volatile may
never b
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 p
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
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 dang
On 05/14/2008 10:55 AM, Emmanuel Lecharny wrote:
Sangjin Lee wrote:
Hmm... Could you share a simple example of a non-volatile variable that
respects the volatile contract?
any boolean.
This is incorrect. Changes made to a boolean that is not volatile may
never become visible in another
On Thu, 15 May 2008 01:20:37 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> 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) a
이희승 (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 class
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
Sangjin Lee wrote:
Hmm... Could you share a simple example of a non-volatile variable that
respects the volatile contract?
any boolean.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Hmm... Could you share a simple example of a non-volatile variable that
respects the volatile contract?
Thanks,
Sangjin
On Wed, May 14, 2008 at 8:38 AM, Emmanuel Lecharny <[EMAIL PROTECTED]>
wrote:
> Sangjin Lee wrote:
>
>> If it wasn't obvious (I guess it was not), what I meant was "using
>> n
Sangjin Lee wrote:
If it wasn't obvious (I guess it was not), what I meant was "using
non-volatile variables *in the absence of any synchronization* ...". :)
Even then, this is not dangerous, as far as you respect the Volatile
contract. Synchronization is not needed in this case.
--
--
cord
[
https://issues.apache.org/jira/browse/DIRMINA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596796#action_12596796
]
Trustin Lee commented on DIRMINA-379:
-
Stefano, you are using MINA 1.x, right? MINA 2
I agree with Emmanuel: volatile might be good enough if you *only*
care about *visibility* but a synchronized block makes the intention
of the code more clear.
Are the performance benefits of volatile substantial ?
I would guess not.
Maarten
On Wed, May 14, 2008 at 5:17 PM, Emmanuel Lecharny <[
If it wasn't obvious (I guess it was not), what I meant was "using
non-volatile variables *in the absence of any synchronization* ...". :)
Regards,
Sangjin
On Wed, May 14, 2008 at 8:17 AM, Emmanuel Lecharny <[EMAIL PROTECTED]>
wrote:
> Sangjin Lee wrote:
>
>> IMHO using non-volatile variables in
On Wed, May 14, 2008 at 7:59 AM, Jeroen Brattinga <
[EMAIL PROTECTED]> 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/wr
Sangjin Lee wrote:
IMHO using non-volatile variables in a multi-threaded
situation is living dangerously.
I don't see how it can be dangerous, as far as you synchronized the code
correctly.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.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 p
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 neede
Daniel and folks,
It seems like we are getting close to consensus.
I concur with you that the stream-like implementation makes a perfect
sense. I'd prefer to roll out our own stream-like real non-blocking
stream and provide a wrapper to InputStream and OutputStream. I think we
can use ja
[
https://issues.apache.org/jira/browse/DIRMINA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596681#action_12596681
]
Stefano Bagnara commented on DIRMINA-379:
-
I see it in a Vista box, never saw it L
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
31 matches
Mail list logo
