JavaScript는 단일 스레드이므로 HTML5의 웹 작업자 다중 스레드

JavaScript는 단일 스레드이므로 HTML5의 웹 작업자는 어떻게 다중 스레드를 수행합니까?

---

HTML5의 웹 작업자에 대해 읽었지만 JavaScript가 단일 스레드라는 것을 알고 있습니다.

내 질문은 다음과 같습니다.

그렇다면 웹 작업자는 어떻게 다중 스레드 작업을 수행하고 있습니까? 또는 진정한 다중 스레드가 아닌 경우 어떻게 시뮬레이션합니까? 여기에서 나에게 명확하지 않은 것 같습니다.

---

여러 의견이 이미 지적했듯이 작업자는 실제로 다중 스레드입니다.

생각을 명확히 하는 데 도움이 될 수 있는 몇 가지 사항:

• JavaScript는 언어이며 스레딩 모델을 정의하지 않으며 반드시 단일 스레드일 필요는 없습니다.
• 대부분의 브라우저는 역사적으로 단일 스레드 였습니다( 빠르게 변화하고 있지만: IE , Chrome , Firefox ). 대부분의 JavaScript 구현은 브라우저에서 발생합니다.
• 웹 작업자는 JavaScript의 일부가 아니며 JavaScript를 통해 액세스할 수 있는 브라우저 기능입니다.

---

조금 늦었지만 같은 질문을 하고 다음과 같은 답을
찾았습니다. 브라우저의 Javascript는 항상 단일 스레드 이며 근본적인 결과는 변수에 대한 "동시" 액세스(다중 스레드 프로그래밍의 주요 골칫거리)입니다. 실제로 동시가 아닙니다. 이것은 실제로 별도의 스레드에서 실행되고 변수에 대한 동시 액세스는 다소 명시적인 방식으로 처리되어야 하는 웹 작업자를 제외하고 는 사실 입니다 .

나는 JavaScript 닌자는 아니지만 브라우저의 JavaScript는 그것이 사실인지 또는 이러한 믿음 뒤에 있는 근거에 많은 관심을 기울이지 않고 단일 스레드 프로세스로 제공된다는 것도 확신했습니다.
이 가정을 뒷받침하는 간단한 사실은 JavaScript로 프로그래밍할 때 공유 변수에 대한 동시 액세스에 대해 신경 쓸 필요가 없다는 것 입니다. 모든 개발자는 문제에 대해 생각조차 하지 않고 변수에 대한 모든 액세스가 일관된 것처럼 코드를 작성합니다.
즉, 소위 메모리 모델에 대해 걱정할 필요가 없습니다 .

실제로 JavaScript에서 병렬 처리를 포함하기 위해 WebWorkers를 볼 필요가 없습니다. (비동기) AJAX 요청을 생각해 보십시오. 그리고 변수에 대한 동시 액세스를 얼마나 부주의하게 처리할지 생각하십시오.

var counter = 0;

function asyncAddCounter() {
  var xhttp = new XMLHttpRequest();
  xhttp.onreadystatechange = function() {
    if (this.readyState == 4) {
      counter++;
    }
  };
  xhttp.open("GET", "/a/remote/resource", true);
  xhttp.send();
}

asyncAddCounter();
counter++;

counter프로세스의 끝에서 의 가치는 무엇입니까 ? 그것은 입니다 2. "동시에" 읽고 쓰는 것은 중요하지 않습니다 1. 이는 에 대한 액세스 counter가 항상 일관됨 을 의미합니다 . 실제로 두 스레드가 동시에 값에 액세스하는 경우 둘 다 읽기로 시작 0하고 둘 다 1끝에 쓸 수 있습니다.

브라우저에서 원격 리소스의 실제 데이터 가져오기는 개발자에게 숨겨져 있고 내부 작업은 JavaScript API의 범위를 벗어납니다(브라우저에서 JavaScript 명령과 관련하여 제어할 수 있는 것). 개발자에 관한 한 네트워크 요청 의 결과 는 메인 스레드에 의해 처리됩니다.
간단히 말해서, 요청 의 실제 수행 은 보이지 않지만 콜백 의 호출 (사용자 정의 JavaScript 코드로 결과 처리)은 메인 스레드에 의해 실행됩니다.
아마도 웹 작업자가 아니었다면 "멀티스레딩"이라는 용어가 자바스크립트 세계에 들어오지 않았을 것입니다.

요청 실행 및 콜백 의 비동기 호출은 실제로 멀티스레딩이 아닌 이벤트 루프 를 사용하여 수행됩니다 . 이것은 여러 브라우저와 분명히 Node.js에 해당됩니다. 다음은 일부 참조이며 경우에 따라 약간 구식이지만 주요 아이디어는 오늘날에도 여전히 유지되고 있다고 생각합니다.

• Firefox: 동시성 모델 및 이벤트 루프 - JavaScript | MDN
• Chrome은 특정 OS에서 libevent 를 사용합니다 .
• IE: 이벤트 모델 이해(Internet Explorer)

이 사실이 JavaScript가 다중 스레드가 아닌 이벤트 기반 이라고 말하는 이유 입니다.
따라서 JavaScript는 비동기식 관용구 를 허용 하지만 JavaScript 코드의 병렬 실행(웹 작업자 외부) 은 허용 하지 않습니다 . 비동기식 이라는 용어 는 두 명령의 결과가 스크램블된 순서로 처리될 수 있다는 사실을 나타냅니다.

WebWorkers에 관해서는, 그들은은 다중 스레드 프로세스를 통해 개발자 제어 할 수 있도록 자바 스크립트 API는.
따라서 공유 메모리에 대한 동시 액세스(다른 스레드의 값 읽기 및 쓰기)를 처리하는 명시적인 방법을 제공하며, 이는 무엇보다도 다음과 같은 방법으로 수행됩니다.

• you push data to a web worker (which means that the new thread reads data) by structured clone: The structured clone algorithm - Web APIs | MDN. Essentially there is no "shared" variable, instead the new thread is given a fresh copy of the object.
• you push data to a web worker by transferring ownership of the value: Transferable - Web APIs | MDN. This means that the just one thread can read its value at any time.
• as for the results returned by the web workers (how they "write"), the main thread access the results when prompted to do so (for instance with the instruction thisWorker.onmessage = function(e) {console.log('Message ' + e.data + ' received from worker');}). It must be by means of the usual Event Loop, I must suppose.
• the main thread and the web worker access a truly shared memory, the SharedArrayBuffer, which is thread-safely accessed using the Atomic functions. I found this clearly exposed in this article: JavaScript: From Workers to Shared Memory
• note: webworkers cannot access the DOM, which is truly shared!

---

You spawn a .js file as a "worker", and it runs processes in a separate thread. You can pass JSON data back and forth between it and the "main" thread. Workers don't have access to certain things like the DOM, though.

So if, say, you wanted to solve complicated math problems, you could let the user enter things into the browser, pass those variables off to the worker, let it do the computation in the background while in the main thread you let the user do other things, or show a progress bar or something, and then when the worker's done, it passes the answer back, and you print it to the page. You could even do multiple problems asynchronously and pass back the answers out of order as they finish. Pretty neat!

---

The browser kicks of a thread with the javascript you want to execute. So its a real thread, with this web workers thing, your js is no longer single-threaded.

ReferenceURL : https://stackoverflow.com/questions/9708113/since-javascript-is-single-threaded-how-are-web-workers-in-html5-doing-multi-th