std.concurrency and efficient returns
Jonathan M Davis
jmdavisprog at gmail.com
Sun Aug 1 16:22:10 PDT 2010
On Sunday 01 August 2010 08:55:54 Robert Jacques wrote:
> Hi Jonathan,
> It sounds like what you really want is a task-based parallel programming
> library, as opposed to concurrent thread. I'd recommend Dave Simcha's
> parallelFuture library if you want to play around with this in D
> (http://www.dsource.org/projects/scrapple/browser/trunk/parallelFuture/para
> llelFuture.d). However, parallelFuture is currently unsafe - you need to
> make sure that logically speaking that data the task is being passed is
> immutable. Shared/const/immutable delegates have been brought up before as
> a way to formalize the implicit assumptions of libraries like
> parallelFuture, but nothing has come of it yet.
> As for std.concurrency, immutability is definitely the correct way to go,
> even if it means extra copying: for most jobs the processing should
> greatly out way the cost of copying and thread initialization (though
> under the hood thread pools should help with the latter). A large amount
> of experience dictates that shared mutable data, let alone unprotected
> mutable data, is a bug waiting to happen.
> On a more practical note, if you relaxing either 1) or 2) can cause major
> problems with certain modern GCs, so at a minimum casts should be involved.
I totally agree that for the most part, the message passing as-is is a very good
idea. It's just that there are cases where it would be desirable to actually
hand over data, so that the thread receiving the data owns it, and it doesn't
exist anymore in the sending thread. I'm not sure that that's possible in the
general case as nice as it would be. However, in my specific case - effectively
returning data upon thread termination - I should think that it would be totally
possible since the sending thread is terminating. That would require some extra
functions in std.concurrency however rather than using receive() and send() as
we have them.
In any case, I'll have to look at Dave Simcha's parallelism library. Thanks for
the info.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list