멀티 스레드 JavaScript 런타임 구현의 단점은 무엇입니까? [닫은]

지난 주 동안 멀티 스레드 JavaScript 런타임 구현을 작업했습니다. JavaScriptCore 및 boost를 사용하여 C ++로 만든 개념 증명이 있습니다.

아키텍처는 간단합니다. 런타임에서 기본 스크립트 평가가 완료되면 스레드 풀이 시작되고 스레드 우선 순위에 참여하여 공유 우선 순위 큐에서 태스크 선택을 시작합니다. 두 태스크가 동시에 변수에 액세스하려고하면 원자로 표시되고 액세스를 위해 경쟁합니다. .

문제는이 디자인을 JavaScript 프로그래머에게 보여줄 때 매우 부정적인 피드백을 받고 이유를 모릅니다. 비공개로도 JavaScript는 단일 스레드, 기존 라이브러리를 다시 작성해야하며 gremlins가 계속 작동하면 모든 살아있는 존재를 생성하고 먹을 것이라고 말합니다.

원래 원래 코 루틴 구현 (부스트 컨텍스트 사용)도 있었지만 그것을 버려야했습니다 (JavaScriptCore는 스택에 대해 pedantic입니다). 나는 그들의 분노를 위험에 빠뜨리고 싶지 않기 때문에 언급하지 않기로 결정했습니다.

어떻게 생각해? JavaScript는 단일 스레드를 의미합니까? 혼자 두어야합니까? 모든 사람이 동시 JavaScript 런타임 아이디어에 반대하는 이유는 무엇입니까?

편집 : 프로젝트는 이제 GitHub 에 있으며 직접 실험하고 의견을 알려주십시오.

다음은 경합없이 병렬로 모든 CPU 코어에서 실행되는 약속의 그림입니다.

1) 멀티 스레딩은 매우 어렵습니다. 불행히도 지금까지이 아이디어를 제시 한 방식은 얼마나 어려운지 과소 평가하고 있음을 나타냅니다.

현재로서는 언어에 단순히 "스레드를 추가"하고 나중에 올바르게 수행하고 수행하는 방법에 대해 걱정하는 것처럼 들립니다. 특히:

두 작업이 변수에 동시에 액세스하려고하면 원자로 표시되고 액세스를 위해 경쟁합니다.
...
원자 변수가 모든 것을 해결하지는 못한다는 데 동의하지만 동기화 문제에 대한 해결책을 찾는 것이 다음 목표입니다.

"동기화 문제 해결"없이 Javascript에 스레드를 추가하는 것은 "추가 문제 해결"없이 Javascript에 정수를 추가하는 것과 같습니다. 문제의 본질에 매우 근본적이기 때문에 아무리 원할지라도 특정 솔루션을 염두에두고 멀티 스레딩을 추가 할 가치가 있는지 여부에 대해서는 기본적으로 논의 할 필요가 없습니다.

또한 모든 변수를 원 자성으로 만드는 것은 다중 스레드 프로그램이 단일 스레드 프로그램 보다 성능을 저하시킬 수있는 일종의 일이므로 실제로보다 현실적인 프로그램에서 성능을 테스트하고 무언가를 얻고 있는지 여부를 확인하는 것이 더 중요합니다.

또한 node.js 프로그래머로부터 스레드를 숨기려고하는지 또는 어느 시점에 스레드를 노출하려는 경우 멀티 스레드 프로그래밍을 위해 새로운 Javascript 방언을 효과적으로 만들지 여부는 분명하지 않습니다. 두 옵션 모두 잠재적으로 흥미롭지 만 아직 어느 것을 목표로 삼고 있는지 결정하지 않은 것처럼 들립니다.

따라서 현재 프로그래머에게 단일 스레드 환경에서 동기화 문제에 대한 솔루션이없고 실제 성능을 향상시키는 증거가없고 이러한 문제를 해결할 계획이없는 새로운 다중 스레드 환경으로 전환 할 것을 요청하고 있습니다.

아마 사람들이 당신을 진지하게 받아들이지 않는 이유 일 것입니다.

2) 단일 이벤트 루프의 단순성과 견고성은 큰 이점입니다.

Javascript 프로그래머는 Javascript 언어가 경쟁 조건 및 모든 진정한 멀티 스레딩 프로그래밍을 괴롭히는 기타 교활한 버그로부터 "안전"하다는 것을 알고 있습니다. 그들이 안전을 포기한다는 확신을 포기하도록 설득하기 위해 강력한 주장이 필요하다는 사실은 그들이 책임감있게 만듭니다.

어떻게 든 그 안전성을 유지할 수 없다면 멀티 스레드 node.js로 바꾸고 싶은 사람은 멀티 스레드 애플리케이션을 위해 처음부터 설계된 Go와 같은 언어로 전환하는 것이 더 나을 것입니다.

3) 자바 스크립트는 프로그래머에게 스레드 관리를 직접 노출시키지 않고 이미 "백그라운드 스레드"(WebWorkers) 및 비동기 프로그래밍을 지원합니다.

이러한 기능은 단일 이벤트 루프의 안전성을 포기하지 않으면 서 실제 세계의 Javascript 프로그래머에게 영향을 미치는 많은 일반적인 사용 사례를 이미 해결합니다.

이러한 기능이 해결되지 않고 Javascript 프로그래머가 솔루션을 원한다는 특정 사용 사례가 있습니까? 그렇다면 특정 사용 사례의 맥락에서 multithreaded node.js를 제시하는 것이 좋습니다.

PS는 무엇 설득 것 나를 다중 스레드 Node.js를 구현 전환 시도?

Javascript / node.js에 단순한 멀티 스레딩의 이점이 있다고 생각되는 사소한 프로그램을 작성하십시오. 이 샘플 프로그램에서 일반 노드 및 다중 스레드 노드에서 성능 테스트를 수행하십시오. 사용중인 버전이 버그 나 불안정성을 유발하지 않으면 서 여러 코어의 런타임 성능, 응답 성 및 사용량을 크게 향상 시킨다는 것을 보여주십시오.

그렇게하면 사람들이이 아이디어에 훨씬 더 관심이있는 것을 보게 될 것입니다.

접근 방식에서 문제를 보여주기 위해 여기를 추측하십시오. 어디에도 링크가 없으므로 실제 구현에 대해 테스트 할 수 없습니다 ...

변하지 않는 것이 항상 하나의 변수 값으로 표현되는 것은 아니며 '하나의 변수'는 일반적인 경우 잠금 범위로 충분하지 않기 때문입니다. 예를 들어, 우리가 변하지 않는 것을 상상해보십시오 a+b = 0(은행의 두 계좌와의 잔고). 아래의 두 함수는 변하지 않는 것이 항상 각 함수의 끝 (단일 스레드 JS의 실행 단위) 에서 유지 되도록합니다 .

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

두 개의 스레드를 실행할 때 지금, 당신의 멀티 스레드 세계에서 어떤 일이 발생 withdraw하고 deposit동시에? 고마워 머피

(+ =와-=를 특별하게 다루는 코드가있을 수 있지만 도움이되지 않습니다. 어떤 시점에서는 함수에 로컬 상태가 있고 동시에 두 변수를 '잠글'방법이 없습니다. 위반 될 것입니다.)

편집 : 코드가 의미 적으로 https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a 의 Go 코드와 동등한 경우 내 의견은 정확합니다 ;-)

10 년 전, Brendan Eich (JavaScript를 발명 한 사람)는 Threads Suck 이라는 에세이를 썼습니다.이 글 은 JavaScript의 디자인 신화에 대한 몇 안되는 표준 문서 중 하나입니다.

그것이 올바른지 여부는 또 다른 질문이지만 JavaScript 커뮤니티가 동시성에 대해 어떻게 생각하는지에 큰 영향을 미쳤다고 생각합니다.

원자 적 액세스는 스레드 안전 동작으로 변환되지 않습니다.

예를 들어 해시 맵을 다시 해싱 (예 : 객체에 속성을 추가 할 때)하거나 전역 배열을 정렬하는 등의 업데이트 중에 전역 데이터 구조가 유효하지 않은 경우가 있습니다. 그 동안 다른 스레드가 변수에 액세스 할 수 없습니다. 이것은 기본적으로 전체 읽기-쓰기-쓰기주기를 감지하고이를 잠 가야한다는 것을 의미합니다. 업데이트가 사소하지 않은 경우 문제 영역을 중지시킬 수 있습니다.

Javascript는 처음부터 단일 스레드 및 샌드 박스 처리되었으며 모든 코드는 이러한 가정을 염두에두고 작성되었습니다.

이는 격리 된 컨텍스트와 관련하여 2 개의 개별 컨텍스트가 다른 스레드에서 실행되도록하는 데 큰 이점이 있습니다. 또한 자바 스크립트를 작성하는 사람들은 경쟁 조건 및 기타 다양한 멀티 스레드 pitfal을 처리하는 방법을 알 필요가 없습니다.

접근 방식으로 성능이 크게 향상됩니까?

못 미더운. 당신은 이것을 증명해야합니다.

귀하의 접근 방식으로 코드를보다 쉽고 빠르게 작성할 수 있습니까?

분명히 아닙니다. 멀티 스레드 코드는 단일 스레드 코드보다 여러 번 올바르게 작성하기가 어렵습니다.

당신의 접근 방식이 더 강력 해 질 것입니까?

교착 상태, 경쟁 조건 등은 해결해야 할 악몽입니다.

구현은 동시성을 도입하는 것이 아니라 동시 변경 가능한 공유 상태로 동시성을 구현하는 특정 방법을 도입하는 것입니다. 역사적으로 사람들은 이러한 유형의 동시성을 사용하여 많은 종류의 문제를 일으켰습니다. 물론 공유 가능한 가변 상태 동시성을 사용하여 완벽하게 작동하는 간단한 프로그램을 만들 수 있지만 메커니즘의 실제 테스트는 수행 할 수있는 것이 아니라 프로그램이 복잡해지고 점점 더 많은 기능이 프로그램에 추가됨에 따라 확장 될 수 있습니다. 소프트웨어는 한 번만 구축하면 완료되는 정적 인 것이 아니라 시간이 지남에 따라 계속 발전하고 메커니즘이나 개념이

다른 모델의 동시성 (예 : 메시지 전달)을보고 해당 모델이 제공하는 이점의 종류를 파악할 수 있습니다.

이것은 필요합니다. 노드 js에 낮은 수준의 동시성 메커니즘이 없기 때문에 수학 및 생물 정보학 등의 분야에서 응용 프로그램의 응용 프로그램이 제한됩니다. 게다가 스레드와의 동시성이 노드에서 사용되는 기본 동시성 모델과 반드시 ​​충돌하지는 않습니다. ui 프레임 워크 (및 nodejs)와 같은 주요 이벤트 루프가있는 환경에서 스레딩에 대한 잘 알려진 의미가 있으며 여전히 유효한 용도로 사용되는 대부분의 상황에서 지나치게 복잡합니다.

물론, 일반적인 웹 앱에는 스레드가 필요하지 않지만 조금 덜 전통적인 것을 시도해보십시오. 소리가 낮은 수준의 동시성 프리미티브가 없으면 제공하는 다른 것으로 빠르게 저어 줄 것입니다.

나는 그것이 다르고 강력한 아이디어이기 때문에 정말로 믿는다. 당신은 신념 체계에 반대하고 있습니다. 네트워크를 통해 물건이 받아 들여 지거나 대중화되는 것은 가치에 근거하지 않습니다. 또한 아무도 새로운 스택에 적응하기를 원하지 않습니다. 사람들은 너무 다른 것을 자동으로 거부합니다.

소리가 나지 않는 일반 npm 모듈로 만드는 방법을 생각해 내면 일부 사람들이 그것을 사용할 수 있습니다.