std: Start implementing wasm32 atomics #54017

alexcrichton · 2018-09-07T02:01:12Z

This commit is an initial start at implementing the standard library for
wasm32-unknown-unknown with the experimental atomics feature enabled. None of
these changes will be visible to users of the wasm32-unknown-unknown target
because they all require recompiling the standard library. The hope with this is
that we can get this support into the standard library and start iterating on it
in-tree to enable experimentation.

Currently there's a few components in this PR:

Atomic fences are disabled on wasm as there's no corresponding atomic op and
it's not clear yet what the convention should be, but this will change in the
future!
Implementations of Mutex, Condvar, and RwLock were all added based on
the atomic intrinsics that wasm has.
The ReentrantMutex and thread-local-storage implementations panic currently
as there's no great way to get a handle on the current thread's "id" yet.

Right now the wasm32 target with atomics is unfortunately pretty unusable,
requiring a lot of manual things here and there to actually get it operational.
This will likely continue to evolve as the story for atomics and wasm unfolds,
but we also need more LLVM support for some operations like custom global
directives for this to work best.

rust-highfive · 2018-09-07T02:01:15Z

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

rust-highfive · 2018-09-07T02:01:16Z

⚠️ Warning ⚠️

These commits modify submodules.

TimNN · 2018-09-11T17:55:36Z

Ping from triage @shepmaster: This PR requires your review.

alexcrichton · 2018-09-14T01:05:12Z

r? @sfackler

mzji · 2018-09-14T07:13:48Z

src/libcore/sync/atomic.rs

 pub fn fence(order: Ordering) {
+    // On wasm32 it looks like fences aren't implemented in LLVM yet in that


Should we add a FIXME here?

Can we have this panic or fail to compile on wasm rather than being a nop?

@sfackler unfortunately this is used by Arc which means that apps quickly stop working if it fails to compile or panics :(

Alternatively we could remove libstd's usage of fences on wasm, but this seemed like a smaller local change for now

alexcrichton · 2018-09-22T04:55:46Z

ping r? @sfackler

sfackler · 2018-09-23T22:51:49Z

src/libcore/sync/atomic.rs

 pub fn fence(order: Ordering) {
+    // On wasm32 it looks like fences aren't implemented in LLVM yet in that


Can we have this panic or fail to compile on wasm rather than being a nop?

sfackler · 2018-09-24T01:12:44Z

src/libstd/sys/wasm/condvar_atomics.rs

+    #[inline]
+    fn ptr(&self) -> *mut i32 {
+        assert_eq!(mem::size_of::<usize>(), mem::size_of::<i32>());
+        &self.cnt as *const AtomicUsize as *mut usize as *mut i32


It seems like there's one more cast than necessary here, right?

sfackler · 2018-09-24T01:26:31Z

src/libstd/sys/wasm/rwlock_atomics.rs

+    }
+
+    fn dec_writers(&mut self) {
+        let zero = match *self {


zero is () here.

sfackler · 2018-09-24T01:26:57Z

src/libstd/sys/wasm/rwlock_atomics.rs

+// unlocking the lock will notify *all* waiters rather than just readers or just
+// writers. This can cause lots of "thundering stampede" problems. While
+// hopefully correct this implementation is very likely to want to be changed in
+// the future.


This implementation additionally doesn't provide any fairness guarantees, right?

Correct yeah, it's not really that great of an rwlock implementation but I figure it's hopefully at least correct and we can continue to iterate in the future.

sfackler · 2018-09-24T01:28:33Z

src/libstd/sys/wasm/condvar_atomics.rs

+        let ticket = self.cnt.load(SeqCst) as i32;
+        mutex.unlock();
+        let nanos = dur.as_nanos();
+        assert!(nanos <= i64::max_value() as u128);


We assert here but truncate below in sleep on duration overflow. It seems like truncation is probably more reasonable behavior?

Ah right yeah, spurious wakeups!

This commit is an initial start at implementing the standard library for wasm32-unknown-unknown with the experimental `atomics` feature enabled. None of these changes will be visible to users of the wasm32-unknown-unknown target because they all require recompiling the standard library. The hope with this is that we can get this support into the standard library and start iterating on it in-tree to enable experimentation. Currently there's a few components in this PR: * Atomic fences are disabled on wasm as there's no corresponding atomic op and it's not clear yet what the convention should be, but this will change in the future! * Implementations of `Mutex`, `Condvar`, and `RwLock` were all added based on the atomic intrinsics that wasm has. * The `ReentrantMutex` and thread-local-storage implementations panic currently as there's no great way to get a handle on the current thread's "id" yet. Right now the wasm32 target with atomics is unfortunately pretty unusable, requiring a lot of manual things here and there to actually get it operational. This will likely continue to evolve as the story for atomics and wasm unfolds, but we also need more LLVM support for some operations like custom `global` directives for this to work best.

alexcrichton · 2018-10-04T06:25:57Z

ping r? @sfackler

sfackler · 2018-10-05T01:55:26Z

@bors r+

bors · 2018-10-05T01:55:27Z

📌 Commit b4877ed has been approved by sfackler

bors · 2018-10-05T01:57:08Z

⌛ Testing commit b4877ed with merge b8bea5a...

std: Start implementing wasm32 atomics This commit is an initial start at implementing the standard library for wasm32-unknown-unknown with the experimental `atomics` feature enabled. None of these changes will be visible to users of the wasm32-unknown-unknown target because they all require recompiling the standard library. The hope with this is that we can get this support into the standard library and start iterating on it in-tree to enable experimentation. Currently there's a few components in this PR: * Atomic fences are disabled on wasm as there's no corresponding atomic op and it's not clear yet what the convention should be, but this will change in the future! * Implementations of `Mutex`, `Condvar`, and `RwLock` were all added based on the atomic intrinsics that wasm has. * The `ReentrantMutex` and thread-local-storage implementations panic currently as there's no great way to get a handle on the current thread's "id" yet. Right now the wasm32 target with atomics is unfortunately pretty unusable, requiring a lot of manual things here and there to actually get it operational. This will likely continue to evolve as the story for atomics and wasm unfolds, but we also need more LLVM support for some operations like custom `global` directives for this to work best.

bors · 2018-10-05T04:25:27Z

☀️ Test successful - status-appveyor, status-travis
Approved by: sfackler
Pushing b8bea5a to master...

rust-highfive assigned shepmaster Sep 7, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 7, 2018

alexcrichton force-pushed the wasm-atomics2 branch from 9c05f5b to c414c5f Compare September 7, 2018 02:03

rust-highfive assigned sfackler and unassigned shepmaster Sep 14, 2018

mzji reviewed Sep 14, 2018

View reviewed changes

sfackler reviewed Sep 24, 2018

View reviewed changes

alexcrichton force-pushed the wasm-atomics2 branch from c414c5f to 11b9034 Compare September 24, 2018 17:23

alexcrichton force-pushed the wasm-atomics2 branch from 11b9034 to b4877ed Compare September 24, 2018 22:55

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 5, 2018

bors merged commit b4877ed into rust-lang:master Oct 5, 2018

alexcrichton deleted the wasm-atomics2 branch October 8, 2018 20:00

gakonst mentioned this pull request Apr 16, 2020

wasm-pack + serde + AtomicUsize serde-rs/serde#1778

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std: Start implementing wasm32 atomics #54017

std: Start implementing wasm32 atomics #54017

alexcrichton commented Sep 7, 2018

rust-highfive commented Sep 7, 2018

rust-highfive commented Sep 7, 2018

TimNN commented Sep 11, 2018

alexcrichton commented Sep 14, 2018

mzji Sep 14, 2018

sfackler Sep 23, 2018

alexcrichton Sep 24, 2018

alexcrichton commented Sep 22, 2018

sfackler Sep 23, 2018

sfackler Sep 24, 2018

sfackler Sep 24, 2018

sfackler Sep 24, 2018

alexcrichton Sep 24, 2018

sfackler Sep 24, 2018

alexcrichton Sep 24, 2018

alexcrichton commented Oct 4, 2018

sfackler commented Oct 5, 2018

bors commented Oct 5, 2018

bors commented Oct 5, 2018

bors commented Oct 5, 2018

		pub fn fence(order: Ordering) {
		// On wasm32 it looks like fences aren't implemented in LLVM yet in that

std: Start implementing wasm32 atomics #54017

std: Start implementing wasm32 atomics #54017

Conversation

alexcrichton commented Sep 7, 2018

rust-highfive commented Sep 7, 2018

rust-highfive commented Sep 7, 2018

TimNN commented Sep 11, 2018

alexcrichton commented Sep 14, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Sep 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcrichton commented Oct 4, 2018

sfackler commented Oct 5, 2018

bors commented Oct 5, 2018

bors commented Oct 5, 2018

bors commented Oct 5, 2018