ter to another (an agent is either the web page's main program or one of
its web workers), [ ` postMessage ` ](/en-US/docs/Web/API/Worker/postMessage)
and [ structured cloning ](/en-
US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm) is used.

The structured clone algorithm accepts ` SharedArrayBuffer ` objects and typed
arrays mapped onto ` SharedArrayBuffer ` objects. In both cases, the `
SharedArrayBuffer ` object is transmitted to the receiver resulting in a new,
private ` SharedArrayBuffer ` object in the receiving agent (just as for [ `
ArrayBuffer ` ](/en-
US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer) ). However, the
shared data block referenced by the two ` SharedArrayBuffer ` objects is the
same data block, and a side effect to the block in one agent will eventually
become visible in the other agent.

js

    
    
    const sab = new SharedArrayBuffer(1024);
    worker.postMessage(sab);
    

Shared memory can be created and updated simultaneously in workers or the main
thread. Depending on the system (the CPU, the OS, the Browser) it can take a
while until the change is propagated to all contexts. To synchronize, [ atomic
](/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics) operations are
needed.

` SharedArrayBuffer ` objects are used by some web APIs, such as:

  * [ ` WebGLRenderingContext.bufferData() ` ](/en-US/docs/Web/API/WebGLRenderingContext/bufferData)
  * [ ` WebGLRenderingContext.bufferSubData() ` ](/en-US/docs/Web/API/WebGLRenderingContext/bufferSubData)
  * [ ` WebGL2RenderingContext.getBufferSubData() ` ](/en-US/docs/Web/API/WebGL2RenderingContext/getBufferSubData)

###  Security requirements

Shared memory and high-resolution timers were effectively [ disabled at the
start of 2018 ](https://blog.mozilla.org/security/2018/01/03/mitigations-
landing-new-class-timing-attack/) in light of [ Spectre
](https://en.wikipedia.org/wiki/Spectre_\(security_vulnerability\)) . In 2020,
a new, secure approach has been standardized to re-enable shared memory.

As a baseline requirement, your document needs to be in a [ secure context
](/en-US/docs/Web/Security/Secure_Contexts) .

For top-level documents, two headers need to be set to cross-origin isolate
your site:

  * [ ` Cross-Origin-Opener-Policy ` ](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) with ` same-origin ` as value (protects your origin from attackers) 
  * [ ` Cross-Origin-Embedder-Policy ` ](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy) with ` require-corp ` or ` credentialless ` as value (protects victims from your origin) 

http

    
    
    Cross-Origin-Opener-Policy: same-origin
    Cross-Origin-Embedder-Policy: require-corp
    

To check if cross origin isolation has been successful, you can test against
the [ ` crossOriginIsolated ` ](/en-US/docs/Web/API/crossOriginIsolated)
property available to window and worker contexts:

js

    
    
    const myWorker = new Worker("worker.js");
    
    if (crossOriginIsolated) {
      const buffer = new SharedArrayBuffer(16);
      myWorker.postMessage(buffer);
    } else {
      const buffer = new ArrayBuffer(16);
      myWorker.postMessage(buffer);
    }
    

With these two headers set, ` postMessage() ` no longer throws for `
SharedArrayBuffer ` objects and shared memory across threads is therefore
available.

Nested documents and dedicated workers need to set the [ ` Cross-Origin-
Embedder-Policy ` ](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)
header as well, with the same value. No further changes are needed for same-
origin nested documents and subresources. Same-site (but cross-origin) nested
documents and subresources need to set the [ ` Cross-Origin-Resource-Policy `
](/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy) header with `
same-site ` as value. And their cross-origin (and cross-site) counterparts
need to set the same header with ` cross-origin ` as value. Note that setting
the [ ` Cross-Origin-Resource