4 ms·

Don't get too excited for SharedArrayBuffer. Every major browser disabled it to help mitigate spectre, and there's no current road map for re-enablement.

euyyn 9y ago
Do you have a link for this, by chance? I hadn't heard.
- warent 9y ago
  "Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- cmpb 9y ago
  The browser compatibility section of the MDN article[1] lists the various browsers and has footnotes that provide further info on each browser's handling of the situation [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
teraflop 9y ago
I wouldn't be surprised if it stays disabled for a long time; there are plenty of non-Spectre-related timing side-channels that are made possible by shared mutable state.
pseudoramble 9y ago
Speaking of which, while I can see the usefulness of SharedArrayBuffer and Atomics for certain libraries and creating certain functionality, I have had some concerns about these new modules. Specifically, I think it complicates the simple model that ES had going for it for a few reasons: * There's already many potential spots for side-effects and mutability in ES as it is. Now we've introduced another one but it works differently than the rest of the model. * Aside from maintaining order with the event loop and async operations, you really didn't need to worry about shared mutable memory in concurrent environments. Now we need to keep that in mind when we work. * If one needs to work with a SharedArrayBuffer instance, the functions they write need to assume/test that the argument is a SharedArrayBuffer specifically because it needs to deal with that type using a separate module (Atomics). * A smaller point, but it does add to the API surface of ES. That could be confusing as time goes on, especially if a developer is unsure of why SharedArrayBuffer is around. These issues can be dealt with by being very careful and selective of when to use these tools, as well as trying to only use them within libraries or narrow contexts. So they're tolerable for sure, but they are just things that have crossed my mind. That being said, what future plans are there for SharedArrayBuffer/Atomics? Maybe the future holds some ideas that will make things better for this feature.
- deleted 9y ago
  [deleted]
- mikekchar 9y ago
  Having just watched one of Kevlin Henney's many talks on the subject on Youtube, I'm reminded of his mutability and shared state diagram. Since I can't find a copy of it outside of an hour long video, I'll try to replicate it here (sorry for those on mobile): Mutable ^ (Good) | (Bad) | Non-Shared ----------> Shared State | State | (Good) | (Good) Immutable On the top half of the graph you have Mutable state, on the bottom half Immutable. On the left you don't share the state and on the right you do. Everything is fine as long as you don't both mutate the state and share it. Of course, that's what we always feel like we want to do ;-)
  - gitgud 9y ago
    That is a great graph, show's the advantage of Immutable state, but also shows that Mutable state is not strictly always bad.
  - seanwilson 9y ago
    What's the rational behind non-shared mutable state being good? State is a huge source of bugs even if you're just using it locally in my opinion.
    - fny 9y ago
      Simple example: sometimes it's tremendously easier and more performant to write loops with an increment counter. Test it, stick it in a function, and it works just as well as any thing else.
    - polskibus 9y ago
      Actors in actor model have local state.
    - mikekchar 9y ago
matlin 9y ago
I hope they scrap it for a better model. Shared memory + locks is not the only way to handle concurrency and can be difficult to reason about. I don't quite understand what problem it's solving that message passing doesn't already. Anyone have any insight on this?
- white-flame 9y ago
  Parallel scanning of large data sets, like object graphs. You don't want to copy the entire graph to each thread, nor do fine grained passing around of a node per traversal. However, if what this exposes is just an array of bytes, that's less useful as you have to cast your own object model on top of it. Large image data might be still useful as just bytes, with threads running convolutions or NNs on it.
- fzzzy 9y ago
  I think the main use case is to support c++ codebases compiled with emscripten without having to rewrite the whole codebase to not assume shared mutable state.
- hajile 9y ago
  Fundamentally, you have to implement every other approach using locks behind the scenes (with the possible exception of immutable data). It may not be an idea user primitive, but serves library makers well.
- seanmcdirmid 9y ago
  Shared memory + locks isn't about concurrency, but probably about parallelism. If you just need concurrency, then messaging between web workers should be good enough.
- nteon 9y ago
  It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation). I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.
lhnz 9y ago
Are you sure about that? If that's the case, what do you think this means: https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270
- bzbarsky 9y ago
  Just for context: 1) Site isolation is not enabled in Chrome yet. 2) As far as I can tell, there are no plans to enable it in Chrome on Android even when it's enabled on desktop. Yes, this would mean SharedArrayBuffer on desktop but not Android.

euyyn 9y ago

Do you have a link for this, by chance? I hadn't heard.

warent 9y ago
"Note that SharedArrayBuffer was disabled by default in all major browsers on 5 January, 2018 in response to Spectre." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
cmpb 9y ago
The browser compatibility section of the MDN article[1] lists the various browsers and has footnotes that provide further info on each browser's handling of the situation [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#Browser_compatibility https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

teraflop 9y ago

I wouldn't be surprised if it stays disabled for a long time; there are plenty of non-Spectre-related timing side-channels that are made possible by shared mutable state.

pseudoramble 9y ago

Speaking of which, while I can see the usefulness of SharedArrayBuffer and Atomics for certain libraries and creating certain functionality, I have had some concerns about these new modules. Specifically, I think it complicates the simple model that ES had going for it for a few reasons: * There's already many potential spots for side-effects and mutability in ES as it is. Now we've introduced another one but it works differently than the rest of the model. * Aside from maintaining order with the event loop and async operations, you really didn't need to worry about shared mutable memory in concurrent environments. Now we need to keep that in mind when we work. * If one needs to work with a SharedArrayBuffer instance, the functions they write need to assume/test that the argument is a SharedArrayBuffer specifically because it needs to deal with that type using a separate module (Atomics). * A smaller point, but it does add to the API surface of ES. That could be confusing as time goes on, especially if a developer is unsure of why SharedArrayBuffer is around. These issues can be dealt with by being very careful and selective of when to use these tools, as well as trying to only use them within libraries or narrow contexts. So they're tolerable for sure, but they are just things that have crossed my mind. That being said, what future plans are there for SharedArrayBuffer/Atomics? Maybe the future holds some ideas that will make things better for this feature.

deleted 9y ago
[deleted]
mikekchar 9y ago
Having just watched one of Kevlin Henney's many talks on the subject on Youtube, I'm reminded of his mutability and shared state diagram. Since I can't find a copy of it outside of an hour long video, I'll try to replicate it here (sorry for those on mobile): Mutable ^ (Good) | (Bad) | Non-Shared ----------> Shared State | State | (Good) | (Good) Immutable On the top half of the graph you have Mutable state, on the bottom half Immutable. On the left you don't share the state and on the right you do. Everything is fine as long as you don't both mutate the state and share it. Of course, that's what we always feel like we want to do ;-)
- gitgud 9y ago
  That is a great graph, show's the advantage of Immutable state, but also shows that Mutable state is not strictly always bad.
- seanwilson 9y ago
  What's the rational behind non-shared mutable state being good? State is a huge source of bugs even if you're just using it locally in my opinion.
  - fny 9y ago
    Simple example: sometimes it's tremendously easier and more performant to write loops with an increment counter. Test it, stick it in a function, and it works just as well as any thing else.
  - polskibus 9y ago
    Actors in actor model have local state.
  - mikekchar 9y ago

matlin 9y ago

I hope they scrap it for a better model. Shared memory + locks is not the only way to handle concurrency and can be difficult to reason about. I don't quite understand what problem it's solving that message passing doesn't already. Anyone have any insight on this?

white-flame 9y ago
Parallel scanning of large data sets, like object graphs. You don't want to copy the entire graph to each thread, nor do fine grained passing around of a node per traversal. However, if what this exposes is just an array of bytes, that's less useful as you have to cast your own object model on top of it. Large image data might be still useful as just bytes, with threads running convolutions or NNs on it.
fzzzy 9y ago
I think the main use case is to support c++ codebases compiled with emscripten without having to rewrite the whole codebase to not assume shared mutable state.
hajile 9y ago
Fundamentally, you have to implement every other approach using locks behind the scenes (with the possible exception of immutable data). It may not be an idea user primitive, but serves library makers well.
seanmcdirmid 9y ago
Shared memory + locks isn't about concurrency, but probably about parallelism. If you just need concurrency, then messaging between web workers should be good enough.
nteon 9y ago
It isn't the only way to handle concurrency, but they are the only primitives that can be used to port existing code (C/C++/Rust/etc) into the browser sandbox without killing performance, or introducing crazier and unsound primitives (like stack manipulation). I've used SharedArrayBuffers to port things like latex into the browser ( https://browsix.org https://browsix.org ), and without it you can't use wasm or asm.js, you need to interpret C code in JavaScript to save/restore the stack on system calls.

lhnz 9y ago

Are you sure about that? If that's the case, what do you think this means: https://bugs.chromium.org/p/chromium/issues/detail?id=821270 https://bugs.chromium.org/p/chromium/issues/detail?id=821270

bzbarsky 9y ago
Just for context: 1) Site isolation is not enabled in Chrome yet. 2) As far as I can tell, there are no plans to enable it in Chrome on Android even when it's enabled on desktop. Yes, this would mean SharedArrayBuffer on desktop but not Android.