jussi.kalliokoski at gmail.com
Mon Sep 24 07:43:50 PDT 2012
Very nice insight, thanks. I agree with you on the shared state,
transferable ownership is a much more tempting option. Especially since
even immutable shared state is hard to achieve in JS, given we have
getters, setters and proxies, etc.
On Mon, Sep 24, 2012 at 5:12 PM, David Bruant <bruant.d at gmail.com> wrote:
> Le 24/09/2012 14:43, Jussi Kalliokoski a écrit :
> > Hello everyone,
> > I've been thinking a lot about parallel processing in the context of
> > hear what everyone's opinions are about it's problems and so forth,
> > but I don't think an open question like that will give very
> > interesting results, so I have an example problem for discussion
> > (while it seems like a bad idea to me, and unlikely to ever get to the
> > language, what I want to know is everyone's reasoning behind their
> > opinions whether it's for or against).
> The concurrency strawman  defines a concurrency as well as
> parallelism model. So far, it's been expressed as the favorite model for
> general purpose parallelism.
> Different use cases are efficiently solved by different forms of
> parallelism, for instance, there is another strawman on data parallelism
>  for the case of applying the same computation to a large amount of
> > What if we introduce Function#fork(), which would call the function in
> > another thread that shares state with the current one.
> Shared state (no matter how much) always has the same story. 2
> computations units want to access the shared state concurrently, but for
> the sake of the shared state integrity, they can't access the state
> simultaenously. So we need to define a form of mutex (for "MUTual
> EXclusion") for a computation unit to express the intention to use the
> state that should be used by one computation unit at once. With mutexes
> as we know them, used at scale, you end up with deadlocks which are
> nasty bugs to find out and debug.
> This is all a consequence of the idea of shared state.
> Of all this story, 2 parts can be attacked to fix the problem. Either,
> define something better than what we know of mutexes (I have no idea of
> what it would look like, but that's an interesting idea) or get rid of
> shared state.
> The current concurrency strawman is doing the latter.
> One annoying thing of naive no-shared-state systems as we know them is
> that everything has to be copied from a computation unit to another.
> That's not exactly true though. It's always possible to implement a
> copy-on-right mechanism.
> Another idea is to define ownership over data. HTML5 defines
> "transferable" objects  which can be passed back and forth form
> worker to worker but can always be used in one worker at a time. Rust
> has a concept of "unique pointer" which is the same idea.
> Another idea would be to have data structures which live in 2 or more
> computation units, showing just an interface to each and which integrity
> would be taken care of under the hood by the "VM" and not client code.
> This is what local storage does for instance.
> I will fight very hard against the idea of shared state, because there
> are very few benefits against all what it costs in large-scale programs.
>  http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
>  http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss