learn about shared memory in javascript

learn about shared memory in javascript - torok-technology

hello everybody, in this article, I will talk about The Shared memory feature that is a very advanced and powerful feature in JavaScript programming language, the Shared memory feature means that is no any problem or trouble of passing the updated data between the threads and each of thread can do accessing of data and update it at the same time in the shared memory.

this thing seems a good thing, so. In this post, I will explain to you how to use the shared memory feature in your JavaScript program, then you will decide whether this feature is what you want or not.

firstly, the advantages & disadvantages of shared memory feature in  javascript

We always use web workers API to create multiple threads in JavaScript language. The Web Workers API lets us create the worker threads whose are used to make a code execution process in the background, so that makes the main thread is free and able to continue its code execution process, and it possibly processing the user interface events.

the Worker threads run at the same time with the main thread. this process is similar to the synchronous execution process of different parts of the given task. this thing makes You finish more quickly, but it also makes the program still has some of the problems.

Ensuring that each string gets the vital assets and speaks with each other in a convenient way is an assignment in itself, where an incident can bring about a shocking result. Or, then again, in the event that one string is changing information and another is understanding it in the meantime, what do you figure the other string will see? The refreshed or the old information? 

Nonetheless, web laborers are not all that simple to mess up. Amid their correspondence by means of utilizing messages, the information they send each other isn't unique yet a duplicate, which means they don't have similar information. They pass duplicates of information to each other when required. 

Be that as it may, sharing is minding, and different strings may likewise need to take a gander at similar information in the meantime and change them. In this way, restricting sharing is a major no-no. This is the place the SharedArrayBuffer question comes into the photo. It will give us a chance to share twofold information between different strings.

The SharedArrayBuffer object

Rather than passing the information duplicates between threads, we pass duplicates of the SharedArrayBuffer question. A SharedArrayBuffer question focuses on the memory where the information is spared. 

Along these lines, notwithstanding when the duplicates of SharedArrayBuffer are passed between strings, they all will at present point to a similar memory where the first information is spared. The strings, along these lines, can view and refresh the information in that same memory.

the web workers API without using shared memory 

To perceive how a web worker functions without utilizing shared memory, we will make a worker thread and will pass some info and data to it. 

to make that you should create an HTML file and put inside this file the javascript code inside a script tags <script> your code </script> the file will be like this:

index.html

const w = new Worker('worker.js');
var   n = 9;
w.postMessage(n);

Then you create a javascript file and call it worker.js, this file comprises the worker script, the code in the file looks like this:

worker.js

onmessage = (e)=>{
  console.group('[worker]');
  console.log('Data received from main thread: %i', e.data);
  console.groupEnd();
}

so according to the code that you wrote, you will get the following result in your console:
console output

[worker]
Data received from main thread: 9

so now you should remember that data was sent back and forth between threads using this eventpostMessage() method. And the data was received successfully on the other side using the eventmessage handler, as a value of the property of the event data.

Now, if we change the data will it appear updated at the receiving end? Let’s see:

index.html

const w = new Worker('worker.js');
var   n = 9;
w.postMessage(n);
n = 1;

console output

[worker]

Web workers with shared memory

Web specialists with shared memory 

Presently, we will utilize the SharedArrayBuffer protest in a similar illustration. We can make another SharedArrayBuffer example by utilizing the new watchword. The constructor takes one parameter; a length esteem in bytes, determining the measure of the cushion.

index.html

const w = new Worker('worker.js');
buff = new SharedArrayBuffer(1);
var   arr = new Int8Array(buff);
/* setting data */
arr[0] = 9;
/* sending the buffer (copy) to worker */
w.postMessage(buff);

Note that a SharedArrayBuffer protest speaks to just a mutual memory region. To see and change the paired information, we have to utilize a proper information structure (a TypedArray or a DataView protest).

In the index.html record over, another SharedArrayBuffer is made, with just a single byte length. At that point, another Int8Array, which is one sort of TypedArray objects, is utilized to set the information to "9" in the gave byte space.


worker.js

onmessage = (e)=>{
  var arr = new Int8Array(e.data);
  console.group('[worker]');
  console.log('Data received from main thread: %i', arr[0]);
  console.groupEnd();
}

Int8Array is likewise utilized as a part of the laborer, to see the information in the cradle.

The normal esteem shows up in the reassure from the laborer string, which is precisely what we needed:

console output:

[worker]
Data received from main thread: 9

Presently, how about we refresh the information in the fundamental string to check whether the change is reflected in the laborer.

index.html

const w = new Worker('worker.js'),
buff = new SharedArrayBuffer(1);
var   arr = new Int8Array(buff);
/* setting data */
arr[0] = 9;
/* sending the buffer (copy) to worker */
w.postMessage(buff);
/* changing the data */

What's more, as should be obvious beneath, the refresh reflects inside the laborer!


console output

[worker]
Data received from main thread: 1

Be that as it may, the code additionally needs to work the a different way: esteem in the laborer changes at initially, it likewise should be refreshed when it's printed from the fundamental string.

For this situation, our code resembles this:

worker.js

onmessage = (e)=>{
  var arr = new Int8Array(e.data);
  console.group('[worker]');
  console.log('Data received from main thread: %i', arr[0]);
  console.groupEnd();
  /* changing the data */
  arr[0] = 7;
  /* posting to the main thread */
  postMessage('');
}

The information is changed in the laborer and a vacant message is presented on the primary string flagging that the information in the cradle has been changed and is prepared for the fundamental string to be yielded.

index.html

const w = new Worker('worker.js'),
buff = new SharedArrayBuffer(1);
var   arr = new Int8Array(buff);
/* setting data */
arr[0] = 9;
/* sending the buffer (copy) to worker */
w.postMessage(buff);
/* changing the data */
arr[0] = 1;
/* printing the data after the worker has changed it */
w.onmessage = (e)=>{
  console.group('[main]');
  console.log('Updated data received from worker thread: %i', arr[0]);
  console.groupEnd();

And, this works, too! The data in the buffer is same as the data inside the worker.

console output

[worker]
Data received from main thread: 1
[main]
Updated data received from worker thread: 7

Conclusion

As I've specified before, utilizing shared memory in JavaScript isn't without drawbacks. It's up to designers to guarantee that the grouping of execution occurs as anticipated and no two strings are dashing to get similar information in light of the fact that nobody knows who will take the trophy. 

On the off chance that you are occupied with shared memory more, observe the documentation of the Atomics protest. The Atomics question can help you with a portion of the hardships, by lessening the flighty idea of perusing/composing from the mutual memory.