Re: std.parallelism: How to wait all tasks finished?
It seems to me that worker threads will continue as long as the queue isn't empty. So if a task adds another task to the pool, some worker will process the newly enqueued task. No. After taskPool.finish() no way to add new tasks to the queue. taskPool.put will not add new tasks. Then perhaps you need to create a new TaskPool (and make sure that workers add their tasks to the correct task pool), so that you can wait on the first task pool, then wait on the second task pool, etc. auto phase1 = new TaskPool(); //make sure all new tasks are added to phase1 phase1.finish(true); auto phase2 = new TaskPool(); //make sure all new tasks are added to phase2 phase2.finish(true);
Re: std.parallelism: How to wait all tasks finished?
// Next line will block execution until all tasks already in queue finished. // Almost all what I need, but new tasks will not be started. taskPool.finish(true); } Are you sure TaskPool.finish isn't what you're looking for? Signals worker threads to terminate when the queue becomes empty. It seems to me that worker threads will continue as long as the queue isn't empty. So if a task adds another task to the pool, some worker will process the newly enqueued task.
Re: mixin template
mixin template Foo(alias a){ alias Foo=a; }
pragma(msg, Foo!2); // error
template Bar(alias a){ alias Bar=a; }
pragma(msg, Bar!2); // ok
Perhaps I was unclear. What I meant:
What does 'mixin template' do that 'template' does not?
Where would I use 'mixin template'?
As far as I can tell, 'mixin template' does nothing new;
'template' is sufficient. Thus, 'mixin template' seems like
pointless extra syntax.
As I said before, this page http://dlang.org/template-mixin.html
could have replaced all instances of 'mixin template' with
'template' and it would compile (I tested all examples) and run
the same (perhaps not true? I tested about half).
Even the example in TDPL on page 284 works the same when I
replace 'mixin template' with 'template': (this is my slightly
modified version) http://dpaste.dzfl.pl/b582c899fc3f
Re: mixin template
On Friday, 31 January 2014 at 06:24:27 UTC, Dan Killebrew wrote:
mixin template Foo(alias a){ alias Foo=a; }
pragma(msg, Foo!2); // error
template Bar(alias a){ alias Bar=a; }
pragma(msg, Bar!2); // ok
As far as I can tell, 'mixin template' does nothing new;
(besides fail to compile in Timon's reply). I should have said
it does nothing helpful.
Re: std.json tree navigation help
Check out the json module in vibe.d. Maybe copy it into your own application (since it can't be used as a library, yet). http://vibed.org/api/vibe.data.json/ https://github.com/rejectedsoftware/vibe.d
Re: mixin template
Found this: http://forum.dlang.org/thread/ntuysfcivhbphnhnn...@forum.dlang.org#post-mailman.1409.1339356130.24740.digitalmars-d-learn:40puremagic.com If what Jonathan says is true, then http://dlang.org/template-mixin.html should be updated: s/mixin template/template/
Re: Idiomatic way to share mutable data?
On Sunday, 22 December 2013 at 21:07:11 UTC, Charles McAnany
wrote:
Friends,
I'm writing a little molecular simulator. Without boring you
with the details, here's the gist of it:
struct Atom{
double x, vx;
double interaction(Atom a2){
return (a2.x-this.x)^^2; //more complicated in reality
}
}
main(){
Atom[] atoms = (a bunch of atoms in random positions);
foreach(timestep; 1..1000){ //L0
foreach(atom; atoms){ //L1
foreach(partner; atoms){ //L2
atom.vx += atom.interaction(partner)/mass;
//F=ma
}
}
foreach(atom; atoms){ //L3
atom.x += atom.vx * deltaT;
}
}
}
So here's the conundrum: How do I parallelize this efficiently?
The first loop, L0, is not parallelizable at all, and I think
the best speedup will be in parallelizing L1. But I immediately
run into trouble: all the threads need access to all of atoms,
and every atom's position is changed on every pass through L0.
So to do this purely with message passing would involve copying
the entirety of atoms to every thread every L0 pass. Clearly,
shared state is desirable.
But I don't need to be careful about the shared state at all;
L1 only reads Atom.x, and only writes Atom.vx. L3 only reads
Atom.vx and only writes Atom.x There's no data dependency at
all inside L1 and L3.
Is there a way to inform the compiler of this without just
aggressively casting things to shared and immutable?
On that note, how do you pass a reference to a thread (via
send) without the compiler yelling at you? Do you
cast(immutable Atom[]) on send and cast(Atom[]) on receive?
If you're doing a range limited interaction, partition the atoms
spatially and have each core handle a fixed 3D volume. Check out
the NT method
http://www.cs.cmu.edu/afs/cs/academic/class/15869-f11/www/readings/shaw05_ntmethod.pdf
When the core that owns an atom detects that it may be in
interaction range for atom(s) owned by another core, send updates
to that other core.
sending an Exception and print it
I'm sending an exception from a worker thread to the owner thread to be logged/printed. Using DMD64 D Compiler v2.064 http://dpaste.dzfl.pl/7c8b68bd Using std.concurrency prevents me from passing a naked Exception. So the owner receives either a shared or immutable Exception. I can't format a shared Exception: /usr/include/dmd/phobos/std/format.d(2602): Error: static assert unable to format shared objects I can't format an immutable Exception: /usr/include/dmd/phobos/std/format.d(2610): Error: template instance formatObject!(Appender!string, immutable(Exception), char) does not match template declaration formatObject(Writer, T, Char)(ref Writer w, ref T val, ref FormatSpec!Char f) if (hasToString!(T, Char)) What gives? I expected the immutable Exception to be formattable. My current workaround is to cast to const Exception. Is there something else I should be doing here?
Re: sending an Exception and print it
I just wanted to add that the can't format immutable Exception also prevents me from doing this: auto exception = receiveOnly!(immutable Exception)(); because receiveOnly creates a tuple which implements a toString that uses indirectly uses formatObject. So I'm forced to use the slightly more clunky recieve() as seen on DPaste.
