"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fupdeb$pph$1@digitalmars.com...
> Robert Fraser wrote:
>> What does "s can now accept runtime initialized const and invariant case statements" mean? Do you mean switch statements or is this referring to something else?
>
> Oops, just checked the page source, and indeed this refers to switch statements. Sorry!

I think it is a bug in the changelog.  I think he meant to write something like:

<a href="...switchstatement.html">switch statement</a>s can now accept...

-Steve

"Sean Kelly" wrote
> Walter Bright wrote:
>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.029.zip
>>
>> This starts laying the foundation for multiprogramming support:
>>
>> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.013.zip
>
> TLS huh?  Nice!  So what will replace the volatile statement?  As it is, that was the only safe way to perform lock-free operations in D.

You can sort of work around it by wrapping the previously volatile statement in a function, but it seems like having volatile doesn't really hurt anything.  I'm curious to know why it was so bad that it was worth removing...

-Steve

"Walter Bright" wrote
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.029.zip
>
> This starts laying the foundation for multiprogramming support:
>
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.013.zip

"Hidden methods now get a compile time warning rather than a runtime one."

Yay!

The pure function description needs a lot more filling out.  I'm particularly interested in whether mutable heap data can be created and used from inside a pure function, and how that would work with class constructors.  I won't poke you any more, because you did qualify that they aren't really implemented yet :)

Nice work!

-Steve

Sean Kelly wrote:
> TLS huh?  Nice!  So what will replace the volatile statement?  As it is, that was the only safe way to perform lock-free operations in D.

It wasn't safe anyway, because it wasn't implemented. For now, just use synchronized instead.

Steven Schveighoffer wrote:
> You can sort of work around it by wrapping the previously volatile statement in a function, but it seems like having volatile doesn't really hurt anything.  I'm curious to know why it was so bad that it was worth removing...

Because after listening in while experts debated how to do write multithreaded code safely, it became pretty clear that the chances of using volatile statements correctly is very small, even for experts. It's the wrong approach.

== Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
> "Sean Kelly" wrote
> > Walter Bright wrote:
> >> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.029.zip
> >>
> >> This starts laying the foundation for multiprogramming support:
> >>
> >> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.013.zip
> >
> > TLS huh?  Nice!  So what will replace the volatile statement?  As it is, that was the only safe way to perform lock-free operations in D.
> You can sort of work around it by wrapping the previously volatile statement in a function, but it seems like having volatile doesn't really hurt anything.  I'm curious to know why it was so bad that it was worth removing...

...and the function has to be opaque.  And even then, I think there's a risk
that something undesirable may happen--I'd have to give it some thought.
I'd guess that 'volatile' is being deprecated in favor of some sort of C++0x
style atomics, but for the moment D no longer has a solution for this.  It's
a bit upsetting, particularly since it effectively deprecates the atomic library
code I wrote for D some three years ago.  As a point of interest, that code is
structurally very similar to what the C++0x group decided on just last summer,
but it's been around for at least a year and a half longer.


Sean

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Sean Kelly wrote:
> > TLS huh?  Nice!  So what will replace the volatile statement?  As it is, that was the only safe way to perform lock-free operations in D.
> It wasn't safe anyway, because it wasn't implemented. For now, just use synchronized instead.

Um, I thought that the volatile statement effectively turned off optimization in the function containing the volatile block?  This wasn't ideal, but it should have done the trick.


Sean

Sean Kelly wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> It wasn't safe anyway, because it wasn't implemented. For now, just use
>> synchronized instead.
> 
> Um, I thought that the volatile statement effectively turned off optimization
> in the function containing the volatile block?  This wasn't ideal, but it should
> have done the trick.

Just turning off optimization isn't good enough. The processor can reorder things!

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fuqed8$18bm$2@digitalmars.com...
> Steven Schveighoffer wrote:
>> You can sort of work around it by wrapping the previously volatile statement in a function, but it seems like having volatile doesn't really hurt anything.  I'm curious to know why it was so bad that it was worth removing...
>
> Because after listening in while experts debated how to do write multithreaded code safely, it became pretty clear that the chances of using volatile statements correctly is very small, even for experts. It's the wrong approach.

But what about things like accessing memory-mapped registers?  That is, as a hint to the compiler to say "don't inline this; don't cache results in registers"?

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Steven Schveighoffer wrote:
> > You can sort of work around it by wrapping the previously volatile statement in a function, but it seems like having volatile doesn't really hurt anything.  I'm curious to know why it was so bad that it was worth removing...
> Because after listening in while experts debated how to do write multithreaded code safely, it became pretty clear that the chances of using volatile statements correctly is very small, even for experts. It's the wrong approach.

Every tool can be mis-used with insufficient understanding.  Look at shared-
memory multiprogramming for instance.  It's quite easy and understandable
to share a few data structures between threads (which I'd assert is the original
intent anyway), but common practice among non-experts is to use mutexes
to protect code rather than data, and to call across threads willy-nilly.  It's
no wonder the commonly held belief is that multiprogramming is hard.

Regarding lock-free programming in particular, I think it's worth pointing
out that leaving out support for lock-free programming in general excludes
an entire realm of code being written--not only library code to be ultimately
used by everyday programmers, but kernel code and such as well.  Look at
the Linux source code, for example.  As for the C++0x discussions, I feel
that some of the participants of the memory model discussion are experts
in the field and understand quite well the issues involved.


Sean