synchronized vs. C volatile
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>
>> I'm not an expert on this, but if I am not mistaken the shared type
>> will handle the barriers, require atomic ops and prevent reordering
>> 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
> 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.
Hey, that's my sig! I guess you can have it as long as you always make it
More information about the Digitalmars-d