Discuss
  • No Shared State Concurrency in JS (was: Adoption of the Typed Array Specification)

No Shared State Concurrency in JS (was: Adoption of the Typed Array Specification)

# Mark S. Miller (15 years ago)

On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry at gmail.com> wrote:

2010/5/18 Kenneth Russell <kbr at google.com>:

On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

Vladimir Vukicevic vladimir at mozilla.com said:

However, another consideration is that the WebGL spec isn't ES specific, and yet has to depend on typed arrays. So perhaps we're really talking about two different specs: a main typed array spec that uses Web IDL and can

be implemented generically in any language, as well as a separate spec describing ES types that happen to fulfill the requirements of typed arrays.

If that is a concern, how do you expect these interfaces to work with other

languages. In a C++ binding are the view objects and the buffer objects still going be distinct objects or are you expect to merge them into native

C++ objects. I think that there is a pretty fundamental question here: does your (and similar) application need to expose binary buffers that exist

natively in the implementation technology of your subsystem and which can

be interchange among multiple client languages. Or, are you able and willing to directly work with native JavaScript buffer objects (assuming that such things exist) even it that a less natural form of access on your

part. In the first case, “host objects” may be exactly what you need. If

the second is what you would like, then we probably need a EcmaScript extension.

Using hypothetical native JavaScript buffer objects would be compatible with our current relatively simple use of TypedArrays. However, we have begun to explore more advanced use cases including sharing TypedArrays among web workers, and between ECMAScript and browser plugins. In these situations, if we were to use native JavaScript buffer objects, we would need to specify additional behavior for the objects.

This looks like a can of worms to me. Shared buffers break with the shared-nothing and message-passing paradigms and necessitate synchronization primitives.

+1.

weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html, erights.org/talks/promises, nodejs.org/#about, www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html and many many others...

There are two relevant quality metrics here -- correctness and performance. At this point, I think shared state concurrency has rather definitively lost the correctness argument. Correctness aside, the jury is till out on the performance argument. (If the program doesn't need to be correct, I can make it arbitrarily fast anyway.) NodeJS, NGINX, and others show that event loops can be quite competitive on performance, and can beat the hell out of conventional threading systems.

In any case, JavaScript isn't C. For most everyone who's moved on from C and C++, paying a minor performance cost in exchange for massively unburdening the cognitive load on the programmer is considered a good tradeoff. Among these post-C languages, Java's greatest mistake is committing to the shared state concurrency control model. JavaScript has wisely avoided that mistake.

With browsers talking to servers, servers talking to servers, browser frames talking to browser frames with postMessage, and with workers, JavaScript is already doing communicating event loops, even though this choice is not yet found in JavaScript's official semantics. Communicating event loops is a scalable model of concurrency, parallelism, and distributed computing. JavaScript has already made its choice. Let's make the most of it. Mixing models at this point will only give us the worst of both worlds.

At some point I would like to see communicating event loops become an official part of JavaScript's semantics. However, I am not arguing to make that official at this time. We have enough on our plate for ES-next without adding this at this time. However, let's not preclude it either.

# Oliver Hunt (15 years ago)

On May 18, 2010, at 9:04 AM, Mark S. Miller wrote:

On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry at gmail.com> wrote: 2010/5/18 Kenneth Russell <kbr at google.com>:

On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

Vladimir Vukicevic vladimir at mozilla.com said: Using hypothetical native JavaScript buffer objects would be compatible with our current relatively simple use of TypedArrays. However, we have begun to explore more advanced use cases including sharing TypedArrays among web workers, and between ECMAScript and browser plugins. In these situations, if we were to use native JavaScript buffer objects, we would need to specify additional behavior for the objects.

This looks like a can of worms to me. Shared buffers break with the shared-nothing and message-passing paradigms and necessitate synchronization primitives.

+1.

There has not been any suggestion of concurrent access to the same shared buffer that i am aware of (otherwise i would have called this out in the WebGL WG) -- the only thing that has been discussed is interaction with workers, where we sharing of the underlying data buffer was always couched in terms of copy-on-write semantics (eg. make the cloning fast by avoiding cloning if possible)

# Mark S. Miller (15 years ago)

On Tue, May 18, 2010 at 9:14 AM, Oliver Hunt <oliver at apple.com> wrote:

On May 18, 2010, at 9:04 AM, Mark S. Miller wrote:

On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry at gmail.com> wrote:

2010/5/18 Kenneth Russell <kbr at google.com>:

On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

Vladimir Vukicevic vladimir at mozilla.com said: Using hypothetical native JavaScript buffer objects would be compatible with our current relatively simple use of TypedArrays. However, we have begun to explore more advanced use cases including sharing TypedArrays among web workers, and between ECMAScript and browser plugins. In these situations, if we were to use native JavaScript buffer objects, we would need to specify additional behavior for the objects.

This looks like a can of worms to me. Shared buffers break with the shared-nothing and message-passing paradigms and necessitate synchronization primitives.

+1.

There has not been any suggestion of concurrent access to the same shared buffer that i am aware of (otherwise i would have called this out in the WebGL WG) -- the only thing that has been discussed is interaction with workers, where we sharing of the underlying data buffer was always couched in terms of copy-on-write semantics (eg. make the cloning fast by avoiding cloning if possible)

Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it should be a completely transparent, semantics free optimization. Thanks for clearing that up.

# Kenneth Russell (15 years ago)

On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights at google.com> wrote:

On Tue, May 18, 2010 at 9:14 AM, Oliver Hunt <oliver at apple.com> wrote:

On May 18, 2010, at 9:04 AM, Mark S. Miller wrote:

On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry at gmail.com> wrote:

2010/5/18 Kenneth Russell <kbr at google.com>:

On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:

Vladimir Vukicevic vladimir at mozilla.com said:  > Using hypothetical native JavaScript buffer objects would be compatible with our current relatively simple use of TypedArrays. However, we have begun to explore more advanced use cases including sharing TypedArrays among web workers, and between ECMAScript and browser plugins. In these situations, if we were to use native JavaScript buffer objects, we would need to specify additional behavior for the objects.

This looks like a can of worms to me.  Shared buffers break with the shared-nothing and message-passing paradigms and necessitate synchronization primitives.

+1.

There has not been any suggestion of concurrent access to the same shared buffer that i am aware of (otherwise i would have called this out in the WebGL WG) -- the only thing that has been discussed is interaction with workers, where we sharing of the underlying data buffer was always couched in terms of copy-on-write semantics (eg. make the cloning fast by avoiding cloning if possible)

Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it should be a completely transparent, semantics free optimization. Thanks for clearing that up.

I hesitate to mention this, but outside of the WebGL working group some colleagues and I have discussed using a combination of shared buffers and postMessage semantics to achieve direct sharing of buffers' contents. The use case is that a worker repeatedly produces new vertex data to be consumed by the main thread. Without the ability to share one or more buffers directly, the worker thread must repeatedly allocate new storage to be handed off to the main thread. If the main thread does not promptly deallocate this storage, the system will rapidly exhaust available resources.

We are interested in doing some prototypes to see what works. Currently I would not like to specify any behavior in this area or artificially limit the ability to experiment.

# Mark Seaborn (15 years ago)

On Tue, May 18, 2010 at 9:52 PM, Kenneth Russell <kbr at google.com> wrote:

On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights at google.com> wrote:

Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it should be a completely transparent, semantics free optimization. Thanks for clearing that up.

I hesitate to mention this, but outside of the WebGL working group some colleagues and I have discussed using a combination of shared buffers and postMessage semantics to achieve direct sharing of buffers' contents. The use case is that a worker repeatedly produces new vertex data to be consumed by the main thread. Without the ability to share one or more buffers directly, the worker thread must repeatedly allocate new storage to be handed off to the main thread. If the main thread does not promptly deallocate this storage, the system will rapidly exhaust available resources.

Couldn't you provide a fast channel object that is implemented using shared memory, but hide the fact that it is using this buffer, so that only message-passing semantics are exposed?

, Mark

# Kenneth Russell (15 years ago)

On Tue, May 18, 2010 at 2:15 PM, Mark Seaborn <mseaborn at google.com> wrote:

On Tue, May 18, 2010 at 9:52 PM, Kenneth Russell <kbr at google.com> wrote:

On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights at google.com> wrote:

Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it should be a completely transparent, semantics free optimization. Thanks for clearing that up.

I hesitate to mention this, but outside of the WebGL working group some colleagues and I have discussed using a combination of shared buffers and postMessage semantics to achieve direct sharing of buffers' contents. The use case is that a worker repeatedly produces new vertex data to be consumed by the main thread. Without the ability to share one or more buffers directly, the worker thread must repeatedly allocate new storage to be handed off to the main thread. If the main thread does not promptly deallocate this storage, the system will rapidly exhaust available resources.

Couldn't you provide a fast channel object that is implemented using shared memory, but hide the fact that it is using this buffer, so that only message-passing semantics are exposed?

Possibly. There is a large API design space. The difficulty is that the current message passing semantics mandate allocation of storage on the receiving end. If the API were structured to allow the receiver of the message to read it into preexisting storage, that would address some of the problem.