Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10666 > unrolled thread

Volatile keyword

Back to article view | Back to comp.lang.java.programmer

Contents

  Volatile keyword "raphfrk@gmail.com" <raphfrk@gmail.com> - 2011-12-12 04:51 -0800
    Re: Volatile keyword Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-12 14:31 +0000
      Re: Volatile keyword "raphfrk@gmail.com" <raphfrk@gmail.com> - 2011-12-12 06:52 -0800
    Re: Volatile keyword Lew <lewbloch@gmail.com> - 2011-12-12 06:34 -0800
    Re: Volatile keyword markspace <-@.> - 2011-12-12 10:00 -0800
      Re: Volatile keyword Tom Anderson <twic@urchin.earth.li> - 2011-12-12 18:41 +0000
        Re: Volatile keyword Patricia Shanahan <pats@acm.org> - 2011-12-12 11:43 -0800
      Re: Volatile keyword Roedy Green <see_website@mindprod.com.invalid> - 2011-12-12 11:15 -0800
        Re: Volatile keyword Robert Klemme <shortcutter@googlemail.com> - 2011-12-13 08:37 +0100
          Re: Volatile keyword Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-12-12 23:54 -0800
            Re: Volatile keyword Robert Klemme <shortcutter@googlemail.com> - 2011-12-14 19:39 +0100
              Re: Volatile keyword Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-14 10:59 -0800
              Re: Volatile keyword Patricia Shanahan <pats@acm.org> - 2011-12-14 11:00 -0800
                Re: Volatile keyword Robert Klemme <shortcutter@googlemail.com> - 2011-12-14 22:35 +0100
    Re: Volatile keyword Roedy Green <see_website@mindprod.com.invalid> - 2011-12-12 10:55 -0800

#10666 — Volatile keyword

Does this make all read/writes happen in full.

For example, if one thread had

volatile long a = 0xFFFFFFFF00000000L;

<do stuff>

a = ~a;

If another thread read a, would it always give 0xFFFFFFFF00000000 or
0x00000000FFFFFFFF and not partial writes (say it updates 32 bits and
then the next 32 bits).

I understand that if two threads do a++, it might only increment
twice, if they both read the old value at the same time.

Effectively, does the CPU lock the entire 64-bits for the long when
doing the write update, and so other threads either seen the updated
value or the old value?

[toc] | [next] | [standalone]

#10668

raphfrk@gmail.com <raphfrk@gmail.com> wrote:
> Does this make all read/writes happen in full.

That's how it is specified.

> For example, if one thread had
> volatile long a = 0xFFFFFFFF00000000L;
> <do stuff>
> a = ~a;
> If another thread read a, would it always give 0xFFFFFFFF00000000 or
> 0x00000000FFFFFFFF and not partial writes (say it updates 32 bits and
> then the next 32 bits).

That's how it is specified. :-)

> I understand that if two threads do a++, it might only increment
> twice, if they both read the old value at the same time.

"once," but I think you meant "once," anyway, with "only" in the 
context.

Even if more processes did "a = ~a;" concurrently on a volatile long a
with given initialization, then the assumption of always reading either
0xFFFFFFFF00000000 or 0x00000000FFFFFFFF but nothing else would still
be a rather safe bet. (i.e. betting only against hardware-flaws, or
severe bugs in the JVM implementation)  Of course, *which* one of these
values you'd see is not necessarily related to the total number of these
manipulations performed by all threads together (as in the a++ case).

> Effectively, does the CPU lock the entire 64-bits for the long when
> doing the write update, and so other threads either seen the updated
> value or the old value?

That's how it is specified. :-)

[toc] | [prev] | [next] | [standalone]

#10670

On Dec 12, 2:31 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> > I understand that if two threads do a++, it might only increment
> > twice, if they both read the old value at the same time.
>
> "once," but I think you meant "once," anyway, with "only" in the
> context.

Yeah, meant once.

On Dec 12, 2:34 pm, Lew <lewbl...@gmail.com> wrote:
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8....

Thanks, I will have a look.

[toc] | [prev] | [next] | [standalone]

#10669

On Monday, December 12, 2011 4:51:41 AM UTC-8, rap...@gmail.com wrote:
> Does this make all read/writes happen in full.
> 
> For example, if one thread had
> 
> volatile long a = 0xFFFFFFFF00000000L;
> 
> <do stuff>
> 
> a = ~a;
> 
> If another thread read a, would it always give 0xFFFFFFFF00000000 or
> 0x00000000FFFFFFFF and not partial writes (say it updates 32 bits and
> then the next 32 bits).
> 
> I understand that if two threads do a++, it might only increment
> twice, if they both read the old value at the same time.
> 
> Effectively, does the CPU lock the entire 64-bits for the long when
> doing the write update, and so other threads either seen the updated
> value or the old value?

http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.4
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.3.1.4

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10674

On 12/12/2011 4:51 AM, raphfrk@gmail.com wrote:

> Effectively, does the CPU lock the entire 64-bits for the long when
> doing the write update, and so other threads either seen the updated
> value or the old value?


I don't like the word "lock" here because it implies something that 
probably isn't happening.  I think that volatile, even for long and 
double, is specified to be much lighter weight than a lock.

The spec that Lew referred to says they are "atomic" and doesn't mention 
"lock."  I think of them that way, myself, in addition to "light weight" 
as opposed to the more heavy actual lock.

volatile long === light weight & atomic.

(=== here meant to mean "defined to be.")

[toc] | [prev] | [next] | [standalone]

#10675

On Mon, 12 Dec 2011, markspace wrote:

> On 12/12/2011 4:51 AM, raphfrk@gmail.com wrote:
>
>> Effectively, does the CPU lock the entire 64-bits for the long when 
>> doing the write update, and so other threads either seen the updated 
>> value or the old value?
>
> I don't like the word "lock" here because it implies something that probably 
> isn't happening.  I think that volatile, even for long and double, is 
> specified to be much lighter weight than a lock.
>
> The spec that Lew referred to says they are "atomic" and doesn't mention 
> "lock."  I think of them that way, myself, in addition to "light weight" as 
> opposed to the more heavy actual lock.
>
> volatile long === light weight & atomic.
>
> (=== here meant to mean "defined to be.")

I don't think it's *defined to be* lightweight. A sadistic JVM implementor 
could make it heavyweight without violating the spec. However, it is 
indeed *defined in such a way as that it can be implemented as* 
lightweight, which is what i think you were getting at.

I would imagine that on the x86, volatile writes to longs are implemented 
by issuing the store instruction with the LOCK prefix, which prevents 
other cores from using the bus until the instruction completes - it's a 
sort of micro-lock, much lighter-weight than a monitor entry. Although 
here is an interesting thread:

http://stackoverflow.com/questions/78277/how-to-guarantee-64-bit-writes-are-atomic

which indicates that my imagination is completely wrong! Suggestions are 
that (a) aligned 64-bit stores are atomic on Pentiums and later anyway, 
and that (b) you can use FISTP to do an intrinsically atomic 64-bit store 
(although that's a FPU instruction - such is the x86 way).

On the PowerPC, if there isn't an atomic 64-bit store, i think you can use 
the load linked/store conditional instructions: LL the second word, do a 
normal store to the first word, then SC to the second word. Oh no, hang 
on, you can still get a race on the first word. Oh well, i suspect that 
the PowerPC has an atomic 64-bit store anyway.

I have no idea what you'd do on a SPARC. I can't think of any other 
interesting chips for JVMs. ARM, maybe? Even less idea there! Ooh, or the 
ShenWei SW-3? Apparently that uses the MIPS instruction set.

tom

-- 
Politically there are two options: Socialism or barbarism. -- King
Aarthoor

[toc] | [prev] | [next] | [standalone]

#10678

Tom Anderson wrote:
> I have no idea what you'd do on a SPARC.

SPARC has atomic 64-bit stores for aligned data.

Patricia

[toc] | [prev] | [next] | [standalone]

#10677

On Mon, 12 Dec 2011 10:00:09 -0800, markspace <-@.> wrote, quoted or
indirectly quoted someone who said :

>
>I don't like the word "lock" here because it implies something that 
>probably isn't happening.  I think that volatile, even for long and 
>double, is specified to be much lighter weight than a lock.

In a 64-bit java, there is nothing to do.  64-bit reads are atomic
because the hardware is atomic.

In 32 bit, there is an assembler instruction cmpxchg8b designed to let
you implement a light weight atomic 64-bit read.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.
 

[toc] | [prev] | [next] | [standalone]

#10691

On 12.12.2011 20:15, Roedy Green wrote:
> On Mon, 12 Dec 2011 10:00:09 -0800, markspace<-@.>  wrote, quoted or
> indirectly quoted someone who said :
>
>> I don't like the word "lock" here because it implies something that
>> probably isn't happening.  I think that volatile, even for long and
>> double, is specified to be much lighter weight than a lock.

Right, there is no lock, just a memory barrier.

> In a 64-bit java, there is nothing to do.  64-bit reads are atomic
> because the hardware is atomic.

I would be unsure whether that can be generalized.  I can imagine a 64 
bit system which externally uses 32 bit - even though that this would 
not be very likely these days.  But in the past there have been 32 bit 
processors with 16 bit data bus.  So you would need two write operations 
on the bus.  And in a SMP scenario these need not be atomic.  Again, not 
very likely but possible.  Bottom line is that the JVM spec does not 
make any guarantees here (§17.7 see Lew's reference).

> In 32 bit, there is an assembler instruction cmpxchg8b designed to let
> you implement a light weight atomic 64-bit read.

Since you do not know on what JVM your Java program will run when you 
write it (or at least someone can choose to use a different JVM model) 
it is safer to code under the assumption that a long and double write is 
two operations i.e. not atomic.  To remedy that there is AtomicLong. 
For double handling see the end of the JavaDoc at
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#10692

On 12/12/11 11:37 PM, Robert Klemme wrote:
> [...]Bottom line is that the JVM spec does not make
> any guarantees here (§17.7 see Lew's reference).

I think it's worth being careful about "does not make any guarantees 
here".  The implication of 17.7 is that there _is_ in fact a guarantee, 
for certain 64-bit fields marked as "volatile".  Specifically, those 
which are of the type "double" or "long".  This is true even on 32-bit 
systems.

Similarly, 64-bit references (i.e. object references when running with 
the 64-bit JVM) are atomically written.  Of course, in that scenario 
it's a somewhat less interesting guarantee, since there's actually 
64-bit hardware there to support that (as opposed to the 64-bit double 
and long values on 32-bit systems).  But it exists as well.

>> In 32 bit, there is an assembler instruction cmpxchg8b designed to let
>> you implement a light weight atomic 64-bit read.
>
> Since you do not know on what JVM your Java program will run when you
> write it (or at least someone can choose to use a different JVM model)
> it is safer to code under the assumption that a long and double write is
> two operations i.e. not atomic.

There is no need to make that assumption provided the field involved is 
marked "volatile".

Pete

[toc] | [prev] | [next] | [standalone]

#10733

On 12/13/2011 08:54 AM, Peter Duniho wrote:
> On 12/12/11 11:37 PM, Robert Klemme wrote:
>> [...]Bottom line is that the JVM spec does not make
>> any guarantees here (§17.7 see Lew's reference).
>
> I think it's worth being careful about "does not make any guarantees
> here". The implication of 17.7 is that there _is_ in fact a guarantee,
> for certain 64-bit fields marked as "volatile". Specifically, those
> which are of the type "double" or "long". This is true even on 32-bit
> systems.

And what guarantee is there?  Can you unambiguously formulate that and 
provide reference to the JLS so everybody can check it?

>>> In 32 bit, there is an assembler instruction cmpxchg8b designed to let
>>> you implement a light weight atomic 64-bit read.
>>
>> Since you do not know on what JVM your Java program will run when you
>> write it (or at least someone can choose to use a different JVM model)
>> it is safer to code under the assumption that a long and double write is
>> two operations i.e. not atomic.
>
> There is no need to make that assumption provided the field involved is
> marked "volatile".

I beg to differ - but I am eagerly waiting to be convinced otherwise.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#10737

On 12/14/11 10:39 AM, Robert Klemme wrote:
> On 12/13/2011 08:54 AM, Peter Duniho wrote:
>> On 12/12/11 11:37 PM, Robert Klemme wrote:
>>> [...]Bottom line is that the JVM spec does not make
>>> any guarantees here (§17.7 see Lew's reference).
>>
>> I think it's worth being careful about "does not make any guarantees
>> here". The implication of 17.7 is that there _is_ in fact a guarantee,
>> for certain 64-bit fields marked as "volatile". Specifically, those
>> which are of the type "double" or "long". This is true even on 32-bit
>> systems.
>
> And what guarantee is there? Can you unambiguously formulate that and
> provide reference to the JLS so everybody can check it?
>
>>>> In 32 bit, there is an assembler instruction cmpxchg8b designed to let
>>>> you implement a light weight atomic 64-bit read.
>>>
>>> Since you do not know on what JVM your Java program will run when you
>>> write it (or at least someone can choose to use a different JVM model)
>>> it is safer to code under the assumption that a long and double write is
>>> two operations i.e. not atomic.
>>
>> There is no need to make that assumption provided the field involved is
>> marked "volatile".
>
> I beg to differ - but I am eagerly waiting to be convinced otherwise.'
The JLS does specifically say that volatile will ensure atomic 
operations on long and double.

The last paragraph of section 17.7:

"The load, store, read, and write actions on volatile variables are 
atomic, even if the type of the variable is double or long."

<http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28330>

So unless you use a non-conforming "JVM" implementation (which by 
definition isn't really a JVM), then you will *always* have atomic reads 
and atomic writes for volatile doubles and volatile longs.

[toc] | [prev] | [next] | [standalone]

#10738

On 12/14/2011 10:39 AM, Robert Klemme wrote:
> On 12/13/2011 08:54 AM, Peter Duniho wrote:
>> On 12/12/11 11:37 PM, Robert Klemme wrote:
>>> [...]Bottom line is that the JVM spec does not make
>>> any guarantees here (§17.7 see Lew's reference).
>>
>> I think it's worth being careful about "does not make any guarantees
>> here". The implication of 17.7 is that there _is_ in fact a guarantee,
>> for certain 64-bit fields marked as "volatile". Specifically, those
>> which are of the type "double" or "long". This is true even on 32-bit
>> systems.
>
> And what guarantee is there? Can you unambiguously formulate that and
> provide reference to the JLS so everybody can check it?

As indicated in the quoted material, the relevant section is
"17.7 Non-atomic Treatment of double and long"
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#61803

The key paragraph, for this purpose, says:

"For the purposes of the Java programming language memory model, a
single write to a non-volatile long or double value is treated as two
separate writes: one to each 32-bit half. This can result in a situation
where a thread sees the first 32 bits of a 64 bit value from one write,
and the second 32 bits from another write. Writes and reads of volatile
long and double values are always atomic. Writes to and reads of
references are always atomic, regardless of whether they are implemented
as 32 or 64 bit values."

Patricia

[toc] | [prev] | [next] | [standalone]

#10748

On 14.12.2011 20:00, Patricia Shanahan wrote:
> On 12/14/2011 10:39 AM, Robert Klemme wrote:
>> On 12/13/2011 08:54 AM, Peter Duniho wrote:
>>> On 12/12/11 11:37 PM, Robert Klemme wrote:
>>>> [...]Bottom line is that the JVM spec does not make
>>>> any guarantees here (§17.7 see Lew's reference).
>>>
>>> I think it's worth being careful about "does not make any guarantees
>>> here". The implication of 17.7 is that there _is_ in fact a guarantee,
>>> for certain 64-bit fields marked as "volatile". Specifically, those
>>> which are of the type "double" or "long". This is true even on 32-bit
>>> systems.
>>
>> And what guarantee is there? Can you unambiguously formulate that and
>> provide reference to the JLS so everybody can check it?
>
> As indicated in the quoted material, the relevant section is
> "17.7 Non-atomic Treatment of double and long"
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#61803

Thank you Patricia and Daniel for helping my feeble eyes!

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#10676

On Mon, 12 Dec 2011 04:51:41 -0800 (PST), "raphfrk@gmail.com"
<raphfrk@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>Does this make all read/writes happen in full.

for the short answer see http://mindprod.com/jgloss/volatile.html

for the long answer see
http://mindprod.com/jgloss/thread.html
and click the link to Goetz's book with the three high speed trains on
the cover.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.
 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web