synchronized vs. C volatile

Steven Schveighoffer schveiguy at yahoo.com
Tue Aug 10 05:44:10 PDT 2010


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

> On Mon, Aug 9, 2010 at 9:55 AM, Lutger <lutger.blijdestijn at 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

:)


More information about the Digitalmars-d mailing list