Concurrency.

[Timon Gehr]

On 11/28/2011 01:57 PM, Debdatta wrote:
> @Michael,
>
> Thanks for clearing that up. Your post was very informative. :)
>
>>> Actually, the private data of your thread object could be used by other
>>> threads if the MyThread object is accessible from another thread and
>>> someone calls a method on it.
>
> Absolutely! However I presume that any self respecting programmer will not manipulate shared data without planning it, or at least thinking about
> it. :D Any self respecting coder would know about memory boundaries, and not arbitrarily modify shared data.
>

Any self respecting coder only writes correct code. That is why there 
are never software bugs.

>>> Not having default sharing is about providing guaranties, it's about
>>> making thread-safety checkable by the compiler.

Nope, it is mostly about providing safe, efficient and convenient 
_defaults_ (that is why it is called no sharing _by default_).

In C#/Java you have those three options:

1. Your variables are shared, but not that much, because you have no 
clue when or if at all or in what order changes to a variable in one 
thread get propagated to other threads. This is the default, of course!

2. Your variables are shared, and the language guarantees sequential 
consistency of the memory location across threads. To get that you need 
to annotate your variables with volatile. That makes sense because 
variables that are not intended to be shared would suffer from a severe 
and pointless performance hit if they would have to behave the same. 
Now, well then those should not be shared at all, right?

3. Thread Local Storage. This is the most obscure of the three.


In D you have those three options:

1. Your variables are thread local. This guarantees some nice 
properties, like code that was intended to run in a single-threaded 
environment when it was written will behave nicely in a multi-threaded 
environment too, because every thread gets a copy of all global data. 
This is a sane default.

2. Your variables are shared and the language guarantees sequential 
consistency (not implemented in DMD yet afaik). This is the 'shared' 
type modifier. shared is transitive (as opposed to volatile in C#/Java), 
but if you feel like it, you can just cast away shared. (preferably you 
should know that it is safe, but as I understand that is the kind of 
stuff you enjoy a lot.)

3. Your variables are shared, but there is no sequential consistency. 
This is __gshared.


If you have a closer look, you will see that there is a 1 to 1 feature 
correspondence there. Nothing to complain about.

>
> No piece of code can absolutely guarantee threading errors. When you start a thread you are most likely doing it because you want to manipulate
> shared data. If you wanted complete memory isolation, with the only means of communication being messages, you would create processes, not threads.
> I understand that this is an over generalization, and the current no default sharing idiom provides less isolation than processes, yo get the drift.
> :D
>
> Threads within a process, by definition(in this case the os defines them), operate within a shared memory space.

As soon as those threads run on different cores with separate deeply 
nested caching hierarchies, that is just an illusion established by 
message passing on the hardware level.


> I don't understand the need to add
> an extra level of complexity in the code, as well as the compiler, by abstracting something thats inherant to the os.
>

There is no extra level of complexity. On the contrary. TLS by default 
is a very easy concept and it accurately reflects the ideal mental model 
for the hardware. The only thing that gets added is a tiny bit of 
explicitness.


> Its like const correctness. You can write more concise, perfectly working programs without it. and all it gives you is an extra check on whether a
> function will modify something, which I, as a programmer, already know.

Nope, it does not do that. In C++, const correctness means that you 
cannot call a non-const method on a const reference and that const 
methods cannot assign to fields of the 'this' reference (unless they are 
marked as 'mutable', that is). And that is it.

D const can provide some guarantees, especially in pure function 
signatures that enable some compiler optimizations. There is also 
'immutable', that gives much stronger guarantees than const.

Furthermore shared is not like const correctness because it (should) 
actually affect the generated code.


> You may interpret my comments as me not wanting to give up control to the
> compiler. In that sense, even a GC is abstracting something thats inherant to the os. :D But the GC gives a huge return on investment, and I don't
> see how the no default sharing rule does.
>

Nobody is giving up control here. You can use type casts to make the 
compiler shut up, or use __gshared data.