Re: Concurrency in D
On Wednesday, 25 February 2015 at 02:04:37 UTC, deadalnix wrote: I have no idea what you mean but: 1/ You should probably be asking in learn. 2/ Most likely, you want std.parallelism Thank you,I've send info in learn,but no person to help me. How to use Fiber and Need help on concurrency
Concurrency in D
There is a int[] ,how to use the Fiber execute it ?
Such as :
import std.stdio;
import core.thread;
class DerivedFiber : Fiber
{
this()
{
super( run );
}
private :
void run()
{
printf( Derived fiber running.\n );
faa();
}
}
int[] v;
void ftread()
{
DerivedFiber work = new DerivedFiber();
writeln( will call );
work.call();
writeln( stop call );
}
void faa()
{
writeln( start );
//Fiber.yield();
writeln( start yield );
foreach(c;v)
{
writeln( current n is ,b(c) );
}
}
void b(int n)
{
...//do someting for n
}
void main()
{
int n=1;
while(n=10_001)
{
v~=n;
n+=5000;
}
printf( Execution returned to calling context.\n );
ftread();
}
-end
I dont's think it's a good work.
How about you?
Thank you.
Re: Concurrency in D
I have no idea what you mean but: 1/ You should probably be asking in learn. 2/ Most likely, you want std.parallelism
Re: Concurrency in D
On Thu, 28 Jun 2012 00:34:50 +0200, Minas Mina wrote: I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). For all those appoaches, which is the preffered? For all those appoaches, which is the preffered for game programming? Thank you. Both std.concurrency and std.parallelism need core.thread in order to do what they do... -- Dejan Lekic mailto:dejan.lekic(a)gmail.com http://dejan.lekic.org
Re: Concurrency in D
On Wednesday, 27 June 2012 at 23:50:17 UTC, Ali Çehreli wrote: On 06/27/2012 04:05 PM, Adam Burton wrote: For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. For this task there is another concurrency module called std.parallelism that is designed for this type of thing (afaik). http://dlang.org/phobos/std_parallelism.html TDPL predates std.parallelism, so it's not in the book. Although the module's documentation is straightforward, I have the following page which may be more accessible for some: http://ddili.org/ders/d.en/parallelism.html Clicking [Next] on that pages goes to Message Passing Concurrency: http://ddili.org/ders/d.en/concurrency.html Ali P.S. Both of those pages are incomplete in some ways, which I will address soon. Much better than the library reference :)
Re: Concurrency in D
yeah, I didn't knew std.parallelism was so easy to use. Speed up was really big for minimal effort.
Concurrency in D
I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). For all those appoaches, which is the preffered? For all those appoaches, which is the preffered for game programming? Thank you.
Re: Concurrency in D
Minas Mina wrote: I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). I've not really got around to doing any concurrent programming in anger with D yet but from what I've read message passing is the preferred method. Fortunately when it comes to answering your question the concurrency chapter for The D Programming Language book (TDPL) was made freely available as a preview http://www.informit.com/articles/article.aspx?p=1609144. Hopefully that contains your answers :). Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? From what I gather this is where the shared keyword typically comes into play which should be detailed in the url above. For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. For this task there is another concurrency module called std.parallelism that is designed for this type of thing (afaik). http://dlang.org/phobos/std_parallelism.html 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). For all those appoaches, which is the preffered? My observation is std.concurrency is being pushed as the preferred default method. For all those appoaches, which is the preffered for game programming? Thank you.
Re: Concurrency in D
On Thu, 28 Jun 2012 00:34:50 +0200, Minas Mina wrote: I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). For all those appoaches, which is the preffered? For all those appoaches, which is the preffered for game programming? Thank you. Concurrency and parallelism are two related, but different concepts. Concurrency is when you have different computations conducted simultaneously. An example is a modern game engine: you may have a rendering thread, a physics simulation, and a networking stack all operating at the same time on different cores. Concurrency allows (and generally assumes) communication between these parts as they need to share information. Message-passing is, as far as I know, pretty much the only truly correct way of doing this. Parallelism is, by contrast, the decomposing of a computation into smaller chunks which do not depend on each other. A trivial example is incrementing all integers in an array by one--the result of the increment computation only relies on the integer being worked on, so the computations may be performed in parallel and the results collected. The std.concurrency and std.parallelism thus exist to solve two different problems and are more of an apples-oranges situation. Justin
Re: Concurrency in D
On Wednesday, 27 June 2012 at 22:34:51 UTC, Minas Mina wrote: I have been playing latetly with std.concurrency and core.thread. I like both, but they are entirely different approaches to concurrency. Aren't they great? ;) std.concurrency: Uses message passing. Does not allow passing of mutable types. core.thread: Essentially the same as the approach taken by Java. 1) Is one favoured over the other? I guess std.concurrency would be, because it uses messages (and I recently read somewhere that immutability + message passing = good thing). Personally I favor std.concurrency, in many cases I find it faster. Well, my problem about is, how can send mutable data to another thread? _Can_ I do it? If not, how am I supposed to share data between them? Not everything can be immutable right? Mutable value types can be sent easily, because they are copied. You share data with shared(T) types, e.g. shared(Object) or shared(int[]). However, I try to avoid shared data by keeping it in single threads, and having other threads access parts with message passing. One paradigm is to isolate data into thread objects, threads which have non-shared data on the stack, and have other threads send GetData messages and get ReturnedData messages. For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. Check out this: http://dpaste.dzfl.pl/0f7ccb79 Note that for algorithms like this, you should check out std.parallelism, it's more high-level than std.concurrency. 2) What about core.thread? To do proper sync between threads in core.thread, semaphore, mutexes and stuff like that are needed. Are those good practice in D? Part of D's philosophy is you can get low-level and dirty if you want, but the easy/safe way should also be the fast way. core.thread is there for you, but std.concurrency is easier. Note that std.concurrency is written on top of core.thread. I definitely prefer std.concurrency, but I don't write CPU-intensive stuff anyway, so I'm no expert. 3) I have also read a bit about syncronized classes and shared classes/structs, altough I didn't understand it too much (well I didn't try too much to be honest). Objects of a synchronized class automatically lock/unlock every method call. You don't share stack structs, though maybe shared(StructType)*. For all those appoaches, which is the preffered? For all those appoaches, which is the preffered for game programming? Thank you. Hope I've helped. NMS
Re: Concurrency in D
On 06/27/2012 04:05 PM, Adam Burton wrote: For example I would like to have a thread calculate the sum of the first half of an array while another thread would calculate the other half, and I could add the two results at the end. For this task there is another concurrency module called std.parallelism that is designed for this type of thing (afaik). http://dlang.org/phobos/std_parallelism.html TDPL predates std.parallelism, so it's not in the book. Although the module's documentation is straightforward, I have the following page which may be more accessible for some: http://ddili.org/ders/d.en/parallelism.html Clicking [Next] on that pages goes to Message Passing Concurrency: http://ddili.org/ders/d.en/concurrency.html Ali P.S. Both of those pages are incomplete in some ways, which I will address soon.
Re: Concurrency in D
You all helped, thank you :) I will read the concurrency part tomorrow!
Concurrency in D
Since I'm working on the concurrency model for D, I have to re-read several articles. I decided to combine this task with blogging--it always helps the understanding if you have to relate the topic to others. We are interested in designing a type system that would prevent, or at least minimize, data races in D. There's been research on this, especially in Java, so I started with analyzing Guava, a race-free dialect of Java. This is the post: http://bartoszmilewski.wordpress.com/2009/03/23/types-for-concurrency/ , and here's a link to reddit, if you want to vote for it: http://www.reddit.com/r/programming/comments/86zow/types_for_concurrency/ .
Re: Concurrency in D
Bartosz Milewski Wrote: Since I'm working on the concurrency model for D, I have to re-read several articles. I decided to combine this task with blogging--it always helps the understanding if you have to relate the topic to others. We are interested in designing a type system that would prevent, or at least minimize, data races in D. There's been research on this, especially in Java, so I started with analyzing Guava, a race-free dialect of Java. This is the post: http://bartoszmilewski.wordpress.com/2009/03/23/types-for-concurrency/ , and here's a link to reddit, if you want to vote for it: http://www.reddit.com/r/programming/comments/86zow/types_for_concurrency/ . Any conclusions about what D should do?
Re: Concurrency in D
On Tue, 24 Mar 2009 21:46:32 -0400, Jason House jason.james.ho...@gmail.com wrote: Bartosz Milewski Wrote: Since I'm working on the concurrency model for D, I have to re-read several articles. I decided to combine this task with blogging--it always helps the understanding if you have to relate the topic to others. We are interested in designing a type system that would prevent, or at least minimize, data races in D. There's been research on this, especially in Java, so I started with analyzing Guava, a race-free dialect of Java. This is the post: http://bartoszmilewski.wordpress.com/2009/03/23/types-for-concurrency/ , and here's a link to reddit, if you want to vote for it: http://www.reddit.com/r/programming/comments/86zow/types_for_concurrency/ . Any conclusions about what D should do? I posted some comments to the blog, here’s an expanded version making the D connection: Guava feels like it has over-complicated itself by using an object-centric abstraction. Essentially, there are shared objects and objects local to those shared objects. (There’s no concept of D’s scope in Java as the VM dynamically makes this decision) Most of the discussion on D’s model is thread-centric: shared objects, thread-local objects and scope objects. First, the good ideas 1. The concept of shared objects (Guava Monitors) being able to have and use private helper objects. While this is mainly about performance rather than correctness (at least in D), documenting and enforcing the concept of a member variable that must be contained within an object’s scope is useful, particularly for structs* since they have no protection of their own. Though not mentioned, the ability to debug with these promoted to a fully protected shared object, would help find bugs. The bugs should only come from poorly written functions inside the object’s module and analysis might be possible to prevent this (possibly also a compiler flag). Mentally, I’m calling these scope member variables since D already has the keyword and they cognitively share the same meaning: that this variable is restricted to the scope it’s declared in. Rules: 1) Transitive 2) Assignable only by the ‘new’ statement: new’s behavior (i.e. where it allocates) is dependent on the internal scope type (scope_function, scope_local, scope_shared) which is determined by declaration location. By the way, now that I think about it, scope member variables are similar in concept to mutable functions inside pure functions. And if you’re keeping count, that’s five ownership types, three of which are not programmer declarable and no ‘const’ equivalent in sight. (I posted about ‘final’ variables a few days ago which attempts to solve this problem.) 2. kept/lent are neat, intuitive keyword names. 3. Although, I’ve seen it elsewhere as well, Guava uses a reader/writer monitor to protect access to shared objects. Hence, const (Guava read) members could be executed concurrently. Next, the bad ideas 1. They didn’t break the scope member variables into a separate type. This results in a bunch of compiler analysis and some cognitive load on the programmer. 2. They have ‘new’ methods in which objects don’t have ownership as well as move semantics for value types. Think Unique!(T), since they allow objects as value types. Both of these mechanics types break the locality of memory allocation. This mean you can’t have local-garbage collection heaps which necessitates less efficient, less scalable and higher latency alternatives. 3. They use class centric region boundaries. This seems to add several layers of complexity without any benefit. Particularly, the kept/lent system exists solely because objects need to be passed across this boundary regularly and therefore doing so must be efficient. This seems like a hallmark that the wrong region boundaries where chosen. For instance, a thread-centric boundary avoids the need for a kept/lent system since the local objects don’t exit or enter the thread. (Thread-centric design also fixes bad idea #2, even Unique)
