Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>> Sean Kelly wrote:
>>>>>> I suppose the obvious question here is: what if I want to create a mutex
>>>>>> in D?
>>>>>
>>>>> Why do you need volatile for that?
>>>>
>>>> To restrict compiler optimizations performed on the code.
>>>
>>> The optimizer won't move global or pointer references across a function call boundary.
>>
>> Even if the function is inlined?
> 
> No, but a mutex involves an OS call. Inlining is also easily prevented.

Maybe you two could arrange a time to have a higher bandwidth IM/irc/skype/telephone chat on the subject?  This seems important, but this one-line-at-a-time back and forth style of discussion is going nowhere fast.

--bb

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Sean Kelly wrote:
>>>> Walter Bright wrote:
>>>>> Sean Kelly wrote:
>>>>>> I suppose the obvious question here is: what if I want to create a
>>>>>> mutex in D?
>>>>> Why do you need volatile for that?
>>>> To restrict compiler optimizations performed on the code.
>>> The optimizer won't move global or pointer references across a function
>>> call boundary.
>>
>> Is that true for all compiler's or only DigitalMars ones?
> 
> DM ones certainly. Others, I don't know about.

Perhaps that should be a part of the language spec?  Or at least it be documented that this is a requirement to allow for multiprocessing?

It sounds like a simple enough feature to implement.  (But what do I know?  I haven't written a compiler since a class in college...decades ago.)

Lars Ivar Igesund wrote:
> So you are saying that you're removing (or not going to implement) a feature
> due to a restriction in the DM optimizer?

"volatile" doesn't work in other C++ compilers for multithreaded code. It's a huge screwup. Not only do the optimizers move things about, but the CPU inself reorders things in ways that move things past mutexes, even if the compiler gets it right. Again, see Scott Meyer's doubled checked locking example.

There'll be a way to do lock-free programming. Volatile isn't the right way.

Sean Kelly wrote:
> An OS call isn't always involved.  See, for example: http://en.wikipedia.org/wiki/Futex.

Then you can write the mutex as your own external function which cannot be inlined.

BCS wrote:
> Reply to Walter,
> 
>> No, but a mutex involves an OS call. Inlining is also easily
>> prevented.
>>
> 
> using atomic ASM ops a (single process) mutex can be implemented with no OS interaction at all.

Those use inline assembler (which is fine).

Bill Baxter wrote:
> Maybe you two could arrange a time to have a higher bandwidth IM/irc/skype/telephone chat on the subject?  This seems important, but this one-line-at-a-time back and forth style of discussion is going nowhere fast.

For the moment, if you are really concerned about it, write it in the 2 lines of inline assembler. That's what I've done to do lock-free CAS stuff. It's really not a big deal.

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> Building a whole volatile subsystem into the type system for that is a
>> huge waste of resources.
> 
> I thought volatile was a statement in D, not a type?

It's a type for C and C++.

Walter Bright wrote:
> Sean Kelly wrote:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> Building a whole volatile subsystem into the type system for that is a
>>> huge waste of resources.
>>
>> I thought volatile was a statement in D, not a type?
> 
> It's a type for C and C++.

Right.  And volatile in C/C++ is a mess :-)


Sean

Walter Bright wrote:
> Sean Kelly wrote:
>> An OS call isn't always involved.  See, for example: http://en.wikipedia.org/wiki/Futex.
> 
> Then you can write the mutex as your own external function which cannot be inlined.

And perhaps write portions of that mutex as separate external functions to prevent reordering within the mutex code itself... surely you can see why this isn't terribly appealing.


Sean

Walter Bright wrote:
> Bill Baxter wrote:
>> Maybe you two could arrange a time to have a higher bandwidth IM/irc/skype/telephone chat on the subject?  This seems important, but this one-line-at-a-time back and forth style of discussion is going nowhere fast.
> 
> For the moment, if you are really concerned about it, write it in the 2 lines of inline assembler. That's what I've done to do lock-free CAS stuff. It's really not a big deal.

That's easy for x86 in D, but for other platforms it requires using C or a standalone assembler, which is workable but annoying.  And regarding the assembler approach in general, I label all the asm blocks as volatile for safety (you fixed a ticket I submitted regarding this a few years back).  I know that DMD doesn't optimize within or across asm blocks, but I don't trust that every D compiler does or will do the same.  Particularly since D doesn't actually have a multithreaded memory model.  If it did, I may trust that seeing a 'lock' expression in x86 inline asm would be enough.


Sean