Hi,

I'm a bit confused.

First of all: From what I understand, volatile is merely a compiler reordering fence. It has nothing to do with atomicity, nor synchronization. Is this correct?

Assuming my understanding is correct: Why does DMD suggest using synchronized to replace volatile statements? It doesn't even remotely do the same thing, is much heavier, calls into the runtime, etc.

And further: How are people *really* supposed to prevent compiler reordering in modern D2 programs (without using atomics; they are expensive and wasteful for this)?

Regards,
Alex
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Monday, July 23, 2012 23:28:05 Alex Rønne Petersen wrote:
> Hi,
> 
> I'm a bit confused.
> 
> First of all: From what I understand, volatile is merely a compiler reordering fence. It has nothing to do with atomicity, nor synchronization. Is this correct?
> 
> Assuming my understanding is correct: Why does DMD suggest using synchronized to replace volatile statements? It doesn't even remotely do the same thing, is much heavier, calls into the runtime, etc.
> 
> And further: How are people *really* supposed to prevent compiler reordering in modern D2 programs (without using atomics; they are expensive and wasteful for this)?

If D's volatile is/was anything like C's, it's my understanding the whole
point of it is to tell the compiler that the object could be accessed by
multiple threads simultaneously, so it shouldn't do optimizations or
instruction reordering which screws with that. That being the case,
I thought that shared replaced volatile, not synchronized.

- Jonathan M Davis
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Tue, Jul 24, 2012 at 12:34 AM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Monday, July 23, 2012 23:28:05 Alex Rønne Petersen wrote:
>> Hi,
>>
>> I'm a bit confused.
>>
>> First of all: From what I understand, volatile is merely a compiler reordering fence. It has nothing to do with atomicity, nor synchronization. Is this correct?
>>
>> Assuming my understanding is correct: Why does DMD suggest using synchronized to replace volatile statements? It doesn't even remotely do the same thing, is much heavier, calls into the runtime, etc.
>>
>> And further: How are people *really* supposed to prevent compiler reordering in modern D2 programs (without using atomics; they are expensive and wasteful for this)?
>
> If D's volatile is/was anything like C's, it's my understanding the whole
> point of it is to tell the compiler that the object could be accessed by
> multiple threads simultaneously, so it shouldn't do optimizations or
> instruction reordering which screws with that. That being the case,
> I thought that shared replaced volatile, not synchronized.
>
> - Jonathan M Davis
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

C's volatile guarantees nothing about threading; it's merely intended to tell the compiler that repeated loads/stores to a volatile location are intentional and should not be optimized out or reordered.

D's shared seems to want to tackle concurrency in addition to the above. Not only is this wasteful for low-level programming where all you want are the aforementioned guarantees, it is also highly unportable (as I have ranted about countless times on the NG).

But either way, shared is not implemented. Replacing a language feature with something that's incomplete and doesn't do the same thing is not acceptable in any way. This direction worries me a lot since I was considering trying out some kernel-level development with D.

BTW, the compiler actually advises you to use synchronized if you use volatile without passing -d to the compiler.

Regards,
Alex
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Mon, Jul 23, 2012 at 11:28 PM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> Hi,
>
> I'm a bit confused.
>
> First of all: From what I understand, volatile is merely a compiler reordering fence. It has nothing to do with atomicity, nor synchronization. Is this correct?
>
> Assuming my understanding is correct: Why does DMD suggest using synchronized to replace volatile statements? It doesn't even remotely do the same thing, is much heavier, calls into the runtime, etc.
>
> And further: How are people *really* supposed to prevent compiler reordering in modern D2 programs (without using atomics; they are expensive and wasteful for this)?
>
> Regards,
> Alex

Ping? (Walter?)

Regards,
Alex
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

That all long predates shared. Shared should be used instead.

On 7/24/2012 1:34 PM, Alex Rønne Petersen wrote:
> On Mon, Jul 23, 2012 at 11:28 PM, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>> Hi,
>>
>> I'm a bit confused.
>>
>> First of all: From what I understand, volatile is merely a compiler
>> reordering fence. It has nothing to do with atomicity, nor
>> synchronization. Is this correct?
>>
>> Assuming my understanding is correct: Why does DMD suggest using
>> synchronized to replace volatile statements? It doesn't even remotely
>> do the same thing, is much heavier, calls into the runtime, etc.
>>
>> And further: How are people *really* supposed to prevent compiler
>> reordering in modern D2 programs (without using atomics; they are
>> expensive and wasteful for this)?
>>
>> Regards,
>> Alex
> Ping? (Walter?)
>
> Regards,
> Alex
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
>


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Tue, Jul 24, 2012 at 11:32 PM, Walter Bright <walter@digitalmars.com> wrote:
> That all long predates shared. Shared should be used instead.
>
>
> On 7/24/2012 1:34 PM, Alex Rønne Petersen wrote:
>>
>> On Mon, Jul 23, 2012 at 11:28 PM, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I'm a bit confused.
>>>
>>> First of all: From what I understand, volatile is merely a compiler reordering fence. It has nothing to do with atomicity, nor synchronization. Is this correct?
>>>
>>> Assuming my understanding is correct: Why does DMD suggest using synchronized to replace volatile statements? It doesn't even remotely do the same thing, is much heavier, calls into the runtime, etc.
>>>
>>> And further: How are people *really* supposed to prevent compiler reordering in modern D2 programs (without using atomics; they are expensive and wasteful for this)?
>>>
>>> Regards,
>>> Alex
>>
>> Ping? (Walter?)
>>
>> Regards,
>> Alex
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

But shared can't replace volatile in kernel space. shared means atomics/memory fences which is not what I want - that would just give me unnecessary overhead. I want the proper, standard C semantics of volatile, not the atomicity that people seem to associate with it.

Besides, shared isn't even implemented yet - how can it actually be called a valid replacement for volatile at all, at this point? It seems amazing to me that volatile was deprecated in favor of something that isn't actually implemented (and even more amazing that the error message points to a feature that doesn't do the same thing)...

Note that I'm writing actual kernel code here. I need something that actually works or I can't reliably write this code in D...

Regards,
Alex
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 7/24/2012 2:53 PM, Alex Rønne Petersen wrote:
> But shared can't replace volatile in kernel space. shared means atomics/memory fences which is not what I want - that would just give me unnecessary overhead. I want the proper, standard C semantics of volatile,

C does not have Standard semantics for volatile. It's a giant mess.

> not the atomicity that people seem to associate with it.

Exactly what semantics are you looking for?

> Besides, shared isn't even implemented yet - how can it actually be called a valid replacement for volatile at all, at this point?

D volatile isn't implemented, either.

> It seems amazing to me that volatile was deprecated in favor of something that isn't actually implemented (and even more amazing that the error message points to a feature that doesn't do the same thing)... Note that I'm writing actual kernel code here. I need something that actually works or I can't reliably write this code in D...

I need to know what you're looking for.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Wed, Jul 25, 2012 at 12:11 AM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 7/24/2012 2:53 PM, Alex Rønne Petersen wrote:
>>
>> But shared can't replace volatile in kernel space. shared means atomics/memory fences which is not what I want - that would just give me unnecessary overhead. I want the proper, standard C semantics of volatile,
>
>
> C does not have Standard semantics for volatile. It's a giant mess.

Right, it leaves the exact definition of a volatile access to the compiler. But most relevant C compilers have a fairly sane definition of this. For example, GCC: http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html

>
>
>> not the atomicity that people seem to associate with it.
>
>
> Exactly what semantics are you looking for?

GCC's volatile semantics, pretty much. I want to be able to interact with volatile memory without the compiler thinking it can optimize or reorder (or whatever) my memory accesses. In other words, tell the compiler to back off and leave volatile code alone.

>
>
>> Besides, shared isn't even implemented yet - how can it actually be called a valid replacement for volatile at all, at this point?
>
>
> D volatile isn't implemented, either.

It doesn't insert a compiler reordering fence? Martin Nowak seemed to think that it does, and a lot of old druntime code assumed that it did...

>
>
>> It seems amazing to me that volatile was deprecated in favor of something that isn't actually implemented (and even more amazing that the error message points to a feature that doesn't do the same thing)... Note that I'm writing actual kernel code here. I need something that actually works or I can't reliably write this code in D...
>
>
> I need to know what you're looking for.
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

Regards,
Alex
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

C's volatile garantee that the compiler will not promote the variable to a register and doo all memory read write in order.

This is mandatory if you want to interface with some memory mapped device for instance.

This has nothing to do with concurency.

2012/7/25 Walter Bright <walter@digitalmars.com>

>
> On 7/24/2012 2:53 PM, Alex Rønne Petersen wrote:
>
>> But shared can't replace volatile in kernel space. shared means atomics/memory fences which is not what I want - that would just give me unnecessary overhead. I want the proper, standard C semantics of volatile,
>>
>
> C does not have Standard semantics for volatile. It's a giant mess.
>
>
>  not the atomicity that people seem to associate with it.
>>
>
> Exactly what semantics are you looking for?
>
>
>  Besides, shared isn't even implemented yet - how can it actually be
>> called a valid replacement for volatile at all, at this point?
>>
>
> D volatile isn't implemented, either.
>
>
>  It seems amazing to me that volatile was deprecated in favor of something
>> that isn't actually implemented (and even more amazing that the error message points to a feature that doesn't do the same thing)... Note that I'm writing actual kernel code here. I need something that actually works or I can't reliably write this code in D...
>>
>
> I need to know what you're looking for.
>
>
> ______________________________**_________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-internals<http://lists.puremagic.com/mailman/listinfo/dmd-internals>
>

On 7/24/2012 3:18 PM, Alex Rønne Petersen wrote:
> On Wed, Jul 25, 2012 at 12:11 AM, Walter Bright <walter@digitalmars.com> wrote:
>> On 7/24/2012 2:53 PM, Alex Rønne Petersen wrote:
>>> But shared can't replace volatile in kernel space. shared means
>>> atomics/memory fences which is not what I want - that would just give me
>>> unnecessary overhead. I want the proper, standard C semantics of volatile,
>>
>> C does not have Standard semantics for volatile. It's a giant mess.
> Right, it leaves the exact definition of a volatile access to the
> compiler.

Right, that's why it is incorrect to refer to it as "standard" behavior. Behaviors I've seen include various combinations of:

1. disallowing enregistering
2. preventing folding multiple loads/stores together
3. preventing reordering across expressions with volatiles
4. inserting memory load/store fences



>   But most relevant C compilers have a fairly sane definition
> of this. For example, GCC:
> http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html
>
>>
>>> not the atomicity that people seem to associate with it.
>>
>> Exactly what semantics are you looking for?
> GCC's volatile semantics, pretty much. I want to be able to interact
> with volatile memory without the compiler thinking it can optimize or
> reorder (or whatever) my memory accesses. In other words, tell the
> compiler to back off and leave volatile code alone.

Unfortunately, this is rather vague. For example, how many read/write operations are there in v++? Optimizing is a terminally nebulous concept.


D volatile isn't implemented, either.


> It doesn't insert a compiler reordering fence? Martin Nowak seemed to
> think that it does, and a lot of old druntime code assumed that it
> did...

dmd, all on its own, does not reorder loads and stores across accesses to globals or pointer dereferences. This behavior is inherited from dmc, and was very successful. dmc generated code simply did not suffer from all kinds of heisenbugs common with other compilers because of that. I've always considered reordering stores to globals as a bad thing to rely on, and not a significant source of performance improvements, so deliberately disabled them.

However, I do understand that the D spec does allow a compiler to do this.

Even though shared is not implemented at the low level, I suggest using it anyway as it currently does work (with or without shared). You should anyway, as the only way there'd be trouble is for multithreaded access to that memory anyway.

As for exact control over read and write cycles, the only reliable way to do that is with inline assembler.

Use these two techniques, and your code should be future proofed.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals