Sharing in D

[Sean Kelly]

== Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> http://www.reddit.com/comments/6u7k0/sharing_in_d/

Sounds like the addition of a thread-local storage class (which
I've been asking for since I discovered D), plus some language
checking on top of that.  I'll admit to being somewhat concerned
that the checking aspect will incur an unwanted runtime expense,
as I don't believe there's any way at compile-time to detect that
a variable is being accessed by multiple threads.  One could try
to assert that non-shared data may never be used in synchronized
blocks, but not all data used in such blocks is actually shared.
In short, I'd love a "thread" storage class, as always, and would
be curious to see how the rest turns out.  It sounds unlikely to
work, but who knows.

That said, data can be shared in one of two ways: either it may
be referenced via a static or global variable or it may be
explicitly passed between two threads.  The latter case is
typically safe because it's deliberate while the former may
well not be.  Thus, the easiest way to get all this working
would be to forbid the use of "static" in a multithreaded app,
or add checking to "static" so it acts like "shared."  That
eliminates the need for a new keyword and makes existing apps
all compile correctly by default.  The final step would be to
require that all static functions either be atomic or contain
a "synchronized" statement.  Easy to do at compile-time and
it would get the job done for the most part.

It's too bad we've been unable to talk about any of this
offline.  We've been considering doing a lot of this sort
of thing with Tango for years now but had been avoiding any
unnecessary runtime changes in hopes that it would increase
the likelihood that the powers that be would get involved.
Obviously, that idea failed :-)  But I'll take this as
implicit permission to have at it, since you seem to be
talking along roughly similar lines for D2 anyway.


Sean