On Sun, 01 Aug 2010 19:22:10 -0400, Jonathan M Davis
<jmdavisp...@gmail.com> wrote:
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.
Oh, sorry I missed that point. That has been seriously discussed before
under the moniker of a 'unique'/'mobile' type. You might want to look up
the dmd-concurrency mailing list or Bartoz's old blogs
bartoszmilewski.wordpress.com. If I recall correctly, there was some plans
to support the library unique struct in std.concurrency. However, Walter
found that trying to fit it into the type system as a whole was too
complex, so the concept is being left to the simpler library solution.
