I hadn't answered as I do not have answers to the questions you ask. My reason: people should not be doing their codes using these low-level shared memory techniques. Data parallel things should be using the std.parallelism module. Dataflow-style things should be using spawn and channels – akin to the way you do things in Go.
So to give you an answer I would go back a stage, forget threads, mutexes, synchronized, etc. and ask what do you want you workers to do? If they are to do something and return a result then spawn and channel is exactly the right abstraction to use. Think "farmer–worker", the farmer spawns the workers and then collects their results. No shared memory anywyere – at least not mutable. On Fri, 2015-09-25 at 15:19 +0000, bitwise via Digitalmars-d-learn wrote: > Hey, I've got a few questions if anybody's got a minute. > > I'm trying to wrap my head around the threading situation in D. > So far, things seem to be working as expected, but I want to > verify my solutions. > > 1) Are the following two snippets exactly equivalent(not just in > observable behaviour)? > a) > > Mutex mut; > mut.lock(); > scope(exit) mut.unlock(); > > b) > Mutex mut; > synchronized(mut) { } > > Will 'synchronized' call 'lock' on the Mutex, or do something > else(possibly related to the interface Object.Monitor)? > > 2) Phobos has 'Condition' which takes a Mutex in the constructor. > The documentation doesn't exactly specify this, but should I > assume it works the same as std::condition_variable in C++? > > For example, is this correct? > > Mutex mut; > Condition cond = new Condition(mut); > > // mut must be locked before calling Condition.wait > synchronized(mut) // depends on answer to (1) > { > // wait() unlocks the mutex and enters wait state > // wait() must re-acquire the mutex before returning when > cond is signalled > cond.wait(); > } > > 3) Why do I have to pass a "Mutex" to "Condition"? Why can't I > just pass an "Object"? > > 4) Will D's Condition ever experience spurious wakeups? > > 5) Why doesn't D's Condition.wait take a predicate? I assume this > is because the answer to (4) is no. > > 6) Does 'shared' actually have any effect on non-global variables > beside the syntactic regulations? > > I know that all global variables are TLS unless explicitly marked > as 'shared', but someone once told me something about 'shared' > affecting member variables in that accessing them from a separate > thread would return T.init instead of the actual value... or > something like that. This seems to be wrong(thankfully). > > For example, I have created this simple Worker class which seems > to work fine without a 'shared' keyword in sight(thankfully). I'm > wondering though, if there would be any unexpected consequences > of doing things this way. > > http://dpaste.com/2ZG2QZV > > > > > Thanks! > Bit -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part