{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/96","repository_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem","labels_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/96/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/96/comments","events_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/96/events","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/96","id":144715422,"number":96,"title":"Non-lock-free atomics + non-atomic exposes tearing","user":{"login":"jfbastien","id":298127,"avatar_url":"https://avatars.githubusercontent.com/u/298127?v=3","gravatar_id":"","url":"https://api.github.com/users/jfbastien","html_url":"https://github.com/jfbastien","followers_url":"https://api.github.com/users/jfbastien/followers","following_url":"https://api.github.com/users/jfbastien/following{/other_user}","gists_url":"https://api.github.com/users/jfbastien/gists{/gist_id}","starred_url":"https://api.github.com/users/jfbastien/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jfbastien/subscriptions","organizations_url":"https://api.github.com/users/jfbastien/orgs","repos_url":"https://api.github.com/users/jfbastien/repos","events_url":"https://api.github.com/users/jfbastien/events{/privacy}","received_events_url":"https://api.github.com/users/jfbastien/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/labels/Memory%20model","name":"Memory model","color":"0052cc"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":16,"created_at":"2016-03-30T20:46:36Z","updated_at":"2016-05-04T13:40:15Z","closed_at":null,"body":"From a discussion at TC39, @waldemarhorwat disagreed when I said that non-lock-free atomics allowed the user to observe tearing when using non-atomics.\r\n\r\nThis falls out of the spec but isn't explicit, so I'd like to get @waldemarhorwat's agreement, and I think we'll want to state it explicitly in the spec.\r\n\r\nConsider this pseudo-code:\r\n```\r\ni64 global = 0;\r\n\r\n// Thread 1:                                   | // Thread 2:\r\nAtomics.store(global, 0xDEADBEEFCAFEC0DE);     | i64 local = global; // Non-atomic load!\r\n                                               | print(global);\r\n```\r\nWhat are the allowed outcomes?\r\n\r\nWhen `isLockFree(8) === 1` then the allowed outcomes are that thread 2 prints either `0` or `0xDEADBEEFCAFEC0DE`.\r\n\r\nWhen `isLockFree(8) === 0 ` then tearing can be observed: `Atomics.store` of a 64-bit value operates by:\r\n\r\n1. Acquiring a lock in the implementation.\r\n  * In C++ this is [provided by gccmm](https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary), the non-lock-free `__atomic_*` operations are in a shared library and usually acquire a lock from a lock-shard (hashed based on the address of the atomic, and potentially the size) to reduce contention. See [compiler-rt](https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c) and [libatomic](https://github.com/gcc-mirror/gcc/blob/master/libatomic/config/posix/lock.c) implementations.\r\n  * In SAB / wasm this would be provided by the VM.\r\n2. Doing the store non-atomically.\r\n3. Unlocking.\r\n\r\nThe non-atomic load is racy. In C++ that's UB, but for SAB we'd like to define what the race can produce. We already guarantee that 32-bit operations are lock-free, the only sane outcome here is that you can print one of `0`, `0xDEADBEEFCAFEC0DE`, `0xDEADBEEF00000000`, or `0x00000000CAFEC0DE`.\r\n\r\nThere are some other interesting things to spec out when non-lock-free accesses are used: what are valid lock implementations? That'll affect what type of tearing can be observed when mixing accesses of different size or when mixing atomic and non-atomic accesses. Again, I think specifying that some interleaving of old+new sub-values can be observed makes sense, without specifying their order."},"comment":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/comments/216867912","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/96#issuecomment-216867912","issue_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/96","id":216867912,"user":{"login":"lars-t-hansen","id":4823190,"avatar_url":"https://avatars.githubusercontent.com/u/4823190?v=3","gravatar_id":"","url":"https://api.github.com/users/lars-t-hansen","html_url":"https://github.com/lars-t-hansen","followers_url":"https://api.github.com/users/lars-t-hansen/followers","following_url":"https://api.github.com/users/lars-t-hansen/following{/other_user}","gists_url":"https://api.github.com/users/lars-t-hansen/gists{/gist_id}","starred_url":"https://api.github.com/users/lars-t-hansen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars-t-hansen/subscriptions","organizations_url":"https://api.github.com/users/lars-t-hansen/orgs","repos_url":"https://api.github.com/users/lars-t-hansen/repos","events_url":"https://api.github.com/users/lars-t-hansen/events{/privacy}","received_events_url":"https://api.github.com/users/lars-t-hansen/received_events","type":"User","site_admin":false},"created_at":"2016-05-04T13:40:15Z","updated_at":"2016-05-04T13:40:15Z","body":"I will add a short comment to the section on lock-freedom to clarify the matter raised here, so that there's less scope for confusion in the future."}}