On Mon, 09 Aug 2010 20:09:54 -0400, SK <[email protected]> wrote:
On Mon, Aug 9, 2010 at 9:55 AM, Lutger <[email protected]>
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
:)
