On Tuesday, 9 April 2013 at 08:31:06 UTC, Manu wrote:
Errrr, no?
Only globals are thread-local. Everything else is either stack
or heap
allocated.
Well, stack is also thread-local, isn't it? ;) Heap objection
accepted.
Yes but that's ultimately useless. If sharing is undefined, and
you can
only use pass something to another thread via shared, then you
basically
can't use threads.
shared is facilitated by blind casting. And codegen (which
doesn't know if
something actually WAS shared or not) can't be assuming it
wasn't.
I can't imagine a situation other than immutable where the
compiler is able
to presume __restrict in this way.
My memories may be vague (I have been reading about it in a
d-concurrency mail list used a looong time ago) but initial
concept was quite elegant: everything that is intended to be
shared should me marked with qualifiers. Function shall accepts
shared parameters, do locks on them (which casts away shared in a
library) and then use in regular functions. This clearly defines
the distinction between functions that need to take care of
synchronization and functions that can just work. I still think
it is a clever concept, but without proper support in D/Phobos
implementation is has become a cumbersome restriction.
Once again, that is what my memory says, I'd like to be corrected
by someone who has actually participated in that mail list.