It's better than never. :)
On Fri, 16 May 2008 05:44:23 +0900, Pauls, Karl <[EMAIL PROTECTED]> 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 implem
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
이희승 (Trustin Lee) wrote:
On Thu, 15 May 2008 16:47:32 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> 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
On Thu, 15 May 2008 16:47:32 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> 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 t
이희승 (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 loc
Hi guys,
First, I want to appologize for the tone I've used in some of my mails
and on IRC. I had a bad day yesturday, and just was too much heated.
Sorry for that, Trustin and David.
Now that I have had a good night sleep, let's address the problem a
little bit more quietly.
Dmitry conce
On Thu, 15 May 2008 16:08:58 +0900, Maarten Bosteels
<[EMAIL PROTECTED]> wrote:
On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee)
<[EMAIL PROTECTED]> wrote:
Yes. I was actually talking about the configuration properties which
meets
the two criteria.
Of course, counters, which were ori
On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> 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 w
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
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
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
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 ment
37 matches
Mail list logo
