www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - synchronized vs. C volatile

reply SK <sk metrokings.com> writes:
Does 'synchronized' mean the exact same thing as the C 'volatile'
qualifier when applied to basic types?
As in:
synchronized int x;
Aug 08 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from SK (sk metrokings.com)'s article

 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


They're completely different.  synchronized is basically a scoped mutex and
applies to a statement, not a variable declaration.  I have no idea what your
example does, but it probably shouldn't even compile.  Volatile just prevents
certain compiler optimizations that can interfere with updates to a variable
from
other hardware besides the CPU and is useful for things like device drivers.
Aug 09 2010
parent reply SK <sk metrokings.com> writes:
On Mon, Aug 9, 2010 at 6:25 AM, dsimcha <dsimcha yahoo.com> wrote:

 =3D=3D Quote from SK (sk metrokings.com)'s article

 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


 They're completely different. =A0synchronized is basically a scoped mutex=


 and

 applies to a statement, not a variable declaration. =A0I have no idea wha=


t your

 example does, but it probably shouldn't even compile. =A0Volatile just pr=


events

 certain compiler optimizations that can interfere with updates to a varia=


ble from

 other hardware besides the CPU and is useful for things like device drive=


rs.


Sounds right to me too.  But the compiler warns about deprecated
'volatile'.  Is the warning a mistake?  Volatile has an important
place in a systems language and I'd rather not mess with tradition
here.

$ cat main.d
int main()
{
        volatile int x =3D 1;
        synchronized int y =3D 1;
        return 0;
}
$ dmd -w -wi main.d
main.d(4): volatile statements deprecated; used synchronized statements ins=
tead



 Aug 09 2010



 next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


SK Wrote:


 On Mon, Aug 9, 2010 at 6:25 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from SK (sk metrokings.com)'s article

 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


 They're completely different.  synchronized is basically a scoped mutex and
 applies to a statement, not a variable declaration.  I have no idea what your
 example does, but it probably shouldn't even compile.  Volatile just prevents
 certain compiler optimizations that can interfere with updates to a variable
from
 other hardware besides the CPU and is useful for things like device drivers.


 
 Sounds right to me too.  But the compiler warns about deprecated
 'volatile'.  Is the warning a mistake?  Volatile has an important
 place in a systems language and I'd rather not mess with tradition
 here.


volatile is present in D1 but was deprecated in D2 in favor of shared.  I
actually liked D1 volatile, but I think I was among the few.  In short, D1
volatile did the bare minimum to ensure that correct multithreaded code could
be implemented by constraining compiler optimizations across volatile statement
boundaries.  For correct synchronized behavior, memory barriers still might
have to be added however.

As an alternative, Walter has stated before that it is invalid for the compiler
to optimize across asm statement boundaries as well, so a similar effect can
often be had by writing inline asm.  Similar requirements apply to shared
variables as well, which can be modified either in-language or by importing
std.concurrency or core.atomic to perform more complex atomic ops.  Both of
these are likely to insert memory barriers when shared variables are accessed
however.



 Aug 09 2010



  parent reply dsimcha <dsimcha yahoo.com>  writes:


== Quote from Sean Kelly (sean invisibleduck.org)'s article

 SK Wrote:

 On Mon, Aug 9, 2010 at 6:25 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from SK (sk metrokings.com)'s article

 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


 They're completely different.  synchronized is basically a scoped mutex and
 applies to a statement, not a variable declaration.  I have no idea what your
 example does, but it probably shouldn't even compile.  Volatile just prevents
 certain compiler optimizations that can interfere with updates to a variable






from

 other hardware besides the CPU and is useful for things like device drivers.


 Sounds right to me too.  But the compiler warns about deprecated
 'volatile'.  Is the warning a mistake?  Volatile has an important
 place in a systems language and I'd rather not mess with tradition
 here.


 volatile is present in D1 but was deprecated in D2 in favor of shared.  I


actually liked D1 volatile, but I think I was among the few.  In short, D1
volatile did the bare minimum to ensure that correct multithreaded code could be
implemented by constraining compiler optimizations across volatile statement
boundaries.  For correct synchronized behavior, memory barriers still might have
to be added however.

 As an alternative, Walter has stated before that it is invalid for the compiler


to optimize across asm statement boundaries as well, so a similar effect can
often
be had by writing inline asm.  Similar requirements apply to shared variables as
well, which can be modified either in-language or by importing std.concurrency
or
core.atomic to perform more complex atomic ops.  Both of these are likely to
insert memory barriers when shared variables are accessed however.

Does this include even empty asm statements, for example:

int i;  // Volatile.

// Do stuff.

asm {}  // No code motion across this.
i++;
asm {} // No code motion across this.

// Do more stuff.



 Aug 09 2010



  parent  Sean Kelly <sean invisibleduck.org>  writes:


dsimcha Wrote:


 == Quote from Sean Kelly (sean invisibleduck.org)'s article

 As an alternative, Walter has stated before that it is invalid for the compiler


 to optimize across asm statement boundaries as well, so a similar effect can
often
 be had by writing inline asm.  Similar requirements apply to shared variables
as
 well, which can be modified either in-language or by importing std.concurrency
or
 core.atomic to perform more complex atomic ops.  Both of these are likely to
 insert memory barriers when shared variables are accessed however.
 
 Does this include even empty asm statements, for example:
 
 int i;  // Volatile.
 
 // Do stuff.
 
 asm {}  // No code motion across this.
 i++;
 asm {} // No code motion across this.
 
 // Do more stuff.


I wondered the same thing when writing my response.  Personally, I wouldn't
consider this safe because the compiler can trivially determine that the block
is empty and make it vanish.  To be safe I think you'd at least have to put a
NOP in there, so I guess you could do something like:

 property void optbar() {
   asm { naked; NOP; }
}

void volatile(lazy void exp) {
    optbar;
    exp();
    optbar;
}

int x;
/*volatile*/ int y;

volatile(x = y);



 Aug 09 2010



prev sibling  parent reply Lutger <lutger.blijdestijn gmail.com>  writes:


SK wrote:


 On Mon, Aug 9, 2010 at 6:25 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from SK (sk metrokings.com)'s article

 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


 They're completely different.  synchronized is basically a scoped mutex and
 applies to a statement, not a variable declaration.  I have no idea what your
 example does, but it probably shouldn't even compile.  Volatile just prevents
 certain compiler optimizations that can interfere with updates to a variable
 from other hardware besides the CPU and is useful for things like device
 drivers.


 
 Sounds right to me too.  But the compiler warns about deprecated
 'volatile'.  Is the warning a mistake?  Volatile has an important
 place in a systems language and I'd rather not mess with tradition
 here.
 
 $ cat main.d
 int main()
 {
         volatile int x = 1;
         synchronized int y = 1;
         return 0;
 }
 $ dmd -w -wi main.d
 main.d(4): volatile statements deprecated; used synchronized statements
 instead



I'm not an expert on this, but if I am not mistaken the shared type qualifier 
will handle the barriers, require atomic ops and prevent reordering compiler 
optimizations so it looks like this one will take care of what volatile used to 
do, right?



 Aug 09 2010



 next sibling parent reply SK <sk metrokings.com>  writes:


On Mon, Aug 9, 2010 at 9:55 AM, Lutger <lutger.blijdestijn gmail.com> wrote:

 I'm not an expert on this, but if I am not mistaken the shared type qualifier
 will handle the barriers, require atomic ops and prevent reordering compiler
 optimizations so it looks like this one will take care of what volatile used to
 do, right?


Right, shared sounds better.  However, atomics must not sneak in:
* Many processors do not support atomics
Even with processor support,
* Many device interconnects do not support atomic transactions
Even with interconnect support,
* Many devices do not support atomic transactions and will just
generate a bus error

So long as code does not attempt a read-modify-write operation, shared
has the opportunity to do the right thing, namely implement volatile
semantics.  Cases with volatile read-modify-write would have to be
split -- awkward, but maybe ok?

asm() hacks to fake volatile are too embarrassing to consider in a
promising new systems language!

-steve



 Aug 09 2010



 next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


SK:

 asm() hacks to fake volatile are too embarrassing to consider in a
 promising new systems language!


D2 has a good chance to become a system language, but it isn't yet.

The main problems don't come from missing features that are easy to add later,
the problems are in the possible presence of suboptimally designed features :-)

Bye,
bearophile



 Aug 10 2010



prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 09 Aug 2010 20:09:54 -0400, SK <sk metrokings.com> wrote:


 On Mon, Aug 9, 2010 at 9:55 AM, Lutger <lutger.blijdestijn gmail.com>  
 wrote:

 I'm not an expert on this, but if I am not mistaken the shared type  
 qualifier
 will handle the barriers, require atomic ops and prevent reordering  
 compiler
 optimizations so it looks like this one will take care of what volatile  
 used to
 do, right?


 Right, shared sounds better.  However, atomics must not sneak in:
 * Many processors do not support atomics
 Even with processor support,
 * Many device interconnects do not support atomic transactions
 Even with interconnect support,
 * Many devices do not support atomic transactions and will just
 generate a bus error


As of now, D supports only x86.  I think it has nestled itself into a  
place where it needs to make tremendous assumptions about the processor  
and OS.  For example, the OS *must* support thread local storage.

Many embedded processors are not even close to as complex as x86, so you  
may not need to worry about a lot of the things D takes care of.  I'd  
expect a version of D for embedded systems may be a different language  
altogether.


 asm() hacks to fake volatile are too embarrassing to consider in a
 promising new systems language!


In the land D is targeting -- namely the application/system space, not the  
kernel space -- volatile is not exactly needed much.  I think shared is  
fine for thread-safe access to variables.  Registers aren't really used in  
user-land code.  I don't pretend to understand why Walter decided volatile  
wasn't adequate, but there were some discussions a while back.


 -steve


Hey, that's my sig!  I guess you can have it as long as you always make it  
lower case.

-Steve

:)



 Aug 10 2010



  parent  Sean Kelly <sean invisibleduck.org>  writes:


Steven Schveighoffer Wrote:

 
 As of now, D supports only x86.  I think it has nestled itself into a  
 place where it needs to make tremendous assumptions about the processor  
 and OS.  For example, the OS *must* support thread local storage.


It doesn't have to be an OS-level thing.  In D, TLS on OSX allocates its
storage dynamically within library code because OSX doesn't support __thread
yet.



 Aug 10 2010



prev sibling  parent reply Kagamin <spam here.lot>  writes:


SK Wrote:


 So long as code does not attempt a read-modify-write operation, shared
 has the opportunity to do the right thing, namely implement volatile
 semantics.  Cases with volatile read-modify-write would have to be
 split -- awkward, but maybe ok?


D provides good behavior by default (for most common cases). If you want
alternative behavior, you can still implement it by, say, casting.
Not D is more targeted for user application development. For kernel development
compiler should be modified (gcc is, for example).



 Aug 11 2010



  parent  Kagamin <spam here.lot>  writes:


Kagamin Wrote:


 Not D is more targeted for user application development.


*Now



 Aug 11 2010



prev sibling  parent  SK <sk metrokings.com>  writes:


On Mon, Aug 9, 2010 at 9:55 AM, Lutger <lutger.blijdestijn gmail.com> wrote:

 I'm not an expert on this, but if I am not mistaken the shared type


qualifier

 will handle the barriers, require atomic ops and prevent reordering


compiler

 optimizations so it looks like this one will take care of what volatile


used to

 do, right?


Seems the latest dmd in svn hasn't implemented shared atomics yet anyway.
If it had, we'd see a lock prefix in use.

$ cat main.d
shared int x = 1;
int main()
{
 x = x + 1;
 ++x;
 return 0;
}
$ dmd -O -w -wi main.d
$ objdump -d main.o

main.o:     file format elf32-i386


Disassembly of section .text:

00000000 <.text>:
   0:   c3                      ret
   1:   60                      pusha
   2:   b8 14 00 00 00          mov    $0x14,%eax
   7:   b9 00 00 00 00          mov    $0x0,%ecx
   c:   8b 11                   mov    (%ecx),%edx
   e:   89 10                   mov    %edx,(%eax)
  10:   89 01                   mov    %eax,(%ecx)
  12:   61                      popa
  13:   c3                      ret

Disassembly of section .text._Dmain:

00000000 <_Dmain>:
   0:   55                      push   %ebp
   1:   a1 00 00 00 00          mov    0x0,%eax
   6:   40                      inc    %eax
   7:   a3 00 00 00 00          mov    %eax,0x0
   c:   8b ec                   mov    %esp,%ebp
   e:   31 c0                   xor    %eax,%eax
  10:   83 05 00 00 00 00 01    addl   $0x1,0x0
  17:   5d                      pop    %ebp
  18:   c3                      ret



 Aug 09 2010



prev sibling next sibling parent reply BCS <none anon.com>  writes:


Hello SK,


 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


I'm reasonably sure that it doesn't. I think synchronized invokes a mutex 
for access and C's volatile just suppresses some optimizations.

-- 
... <IXOYE><



 Aug 09 2010



  parent reply SK <sk metrokings.com>  writes:


On Mon, Aug 9, 2010 at 7:29 AM, BCS <none anon.com> wrote:

 Hello SK,


 Does 'synchronized' mean the exact same thing as the C 'volatile'
 qualifier when applied to basic types?
 As in:
 synchronized int x;


 I'm reasonably sure that it doesn't. I think synchronized invokes a mutex
 for access and C's volatile just suppresses some optimizations.

 --
 ... <IXOYE><


Andrei's book does not list volatile as a keyword in D.  I'm at a loss
unless 'synchronized' performs double duty as volatile.  For example,
device status registers are "const volatile" in C/C++.  The compiler
disallows writes and does not optimize away reads.   Mutexes are
irrelevant and for that matter the processor may not (and need not)
even support atomic instructions.
-steve



 Aug 09 2010



  parent reply Sean Kelly <sean invisibleduck.org>  writes:


SK Wrote:

 
 Andrei's book does not list volatile as a keyword in D.  I'm at a loss
 unless 'synchronized' performs double duty as volatile.  For example,
 device status registers are "const volatile" in C/C++.  The compiler
 disallows writes and does not optimize away reads.   Mutexes are
 irrelevant and for that matter the processor may not (and need not)
 even support atomic instructions.


So you're one of the few people who actually use C volatile as intended, huh?
:-)  I think right now your best bet is to use inline asm, or call out to a
function written in assembly if you're targeting something other than x86.  As
I said in my other post, the compiler won't optimize away ask blocks, nor will
it optimize across them.  Walter has stated that it's incorrect behavior for a
compiler to do so.  GDC or LDC might however, I really couldn't say.



 Aug 09 2010



  parent  bearophile <bearophileHUGS lycos.com>  writes:


Sean Kelly:

As I said in my other post, the compiler won't optimize away ask blocks, nor
will it optimize across them.  Walter has stated that it's incorrect behavior
for a compiler to do so.  GDC or LDC might however, I really couldn't say.<


In LDC there are two ways to inline asm statements and functions that contain
them, but both are explicit, so on default it acts as DMD (but I don't think
this is well tested).

Bye,
bearophile



 Aug 09 2010



prev sibling  parent  Sean Kelly <sean invisibleduck.org>  writes:


SK Wrote:

 
 asm() hacks to fake volatile are too embarrassing to consider in a
 promising new systems language!


I'm not sure I agree.  Unlike C/C++, inline asm in D is a clearly defined
language feature.  Also, making 'volatile' an attribute adds a lot of syntactic
clutter for what really is a niche feature.  That 'volatile' is almost
universally misused in C/C++ supports the assertion that this perhaps should
not be so obvious a language feature in D, particularly since it can be
accomplished in-language via other means.  That D only defines inline asm for
x86 shouldn't much matter.  It's clear that the D approach is to make inline
asm look as much like native asm as possible, so how it will work on other
platforms is easy to extrapolate.  Until support is added for your platform of
choice, just call out to external asm code.



 Aug 10 2010