On Tue, Jul 24, 2012 at 11:32 PM, Walter Bright <[email protected]> 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
>> <[email protected]> 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
>> [email protected]
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>>
>
>
> _______________________________________________
> dmd-internals mailing list
> [email protected]
> 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
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Reply via email to