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.
