On 13.11.2012 10:20, Sönke Ludwig wrote:
Am 13.11.2012 10:14, schrieb luka8088:
On Tuesday, 13 November 2012 at 09:11:15 UTC, luka8088 wrote:
On 12.11.2012 3:30, Walter Bright wrote:
On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
It's starting to get outright embarrassing to talk to newcomers about D's
concurrency support because the most fundamental part of it -- the
shared type
qualifier -- does not have well-defined semantics at all.
I think a couple things are clear:
1. Slapping shared on a type is never going to make algorithms on that
type work in a concurrent context, regardless of what is done with
memory barriers. Memory barriers ensure sequential consistency, they do
nothing for race conditions that are sequentially consistent. Remember,
single core CPUs are all sequentially consistent, and still have major
concurrency problems. This also means that having templates accept
shared(T) as arguments and have them magically generate correct
concurrent code is a pipe dream.
2. The idea of shared adding memory barriers for access is not going to
ever work. Adding barriers has to be done by someone who knows what
they're doing for that particular use case, and the compiler inserting
them is not going to substitute.
However, and this is a big however, having shared as compiler-enforced
self-documentation is immensely useful. It flags where and when data is
being shared. So, your algorithm won't compile when you pass it a shared
type? That is because it is NEVER GOING TO WORK with a shared type. At
least you get a compile time indication of this, rather than random
runtime corruption.
To make a shared type work in an algorithm, you have to:
1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex
Also, all op= need to be disabled for shared types.
This clarifies a lot, but still a lot of people get confused with:
http://dlang.org/faq.html#shared_memory_barriers
is it a faq error ?
and also with http://dlang.org/faq.html#shared_guarantees said, I come to think
that the fact that
the following code compiles is either lack of implementation, a compiler bug or
a faq error ?
//////////
import core.thread;
void main () {
shared int i;
(new Thread({ i++; })).start();
}
Um, sorry, the following code:
//////////
import core.thread;
void main () {
int i;
(new Thread({ i++; })).start();
}
Only std.concurrency (using spawn() and send()) enforces that unshared data
cannot be pass between
threads. The core.thread module is just a low-level module that just represents
the OS functionality.
In that case http://dlang.org/faq.html#shared_guarantees is wrong, it is
not a correct guarantee. Or at least that should be noted there. If
nothing else it is confusing...
