Những nhược điểm của việc thực hiện thời gian chạy JavaScript đa luồng là gì? [đóng cửa]

Tôi đã làm việc trên một triển khai thời gian chạy JavaScript đa luồng trong tuần qua. Tôi có một bằng chứng về khái niệm được tạo trong C ++ bằng JavaScriptCore và boost.

Kiến trúc rất đơn giản: khi bộ thực thi kết thúc việc đánh giá tập lệnh chính, nó khởi chạy và tham gia nhóm luồng, bắt đầu chọn các tác vụ từ hàng đợi ưu tiên chia sẻ, nếu hai tác vụ cố gắng truy cập đồng thời một biến thì nó được đánh dấu nguyên tử và chúng dự định truy cập .

Vấn đề là khi tôi hiển thị thiết kế này cho một lập trình viên JavaScript, tôi nhận được phản hồi cực kỳ tiêu cực và tôi không biết tại sao. Ngay cả ở chế độ riêng tư, tất cả đều nói rằng JavaScript có nghĩa là một luồng đơn, rằng các thư viện hiện tại sẽ phải được viết lại và gremlins sẽ sinh ra và ăn mọi sinh vật nếu tôi tiếp tục làm việc này.

Ban đầu tôi cũng đã triển khai coroutine bản địa (sử dụng bối cảnh tăng cường), nhưng tôi đã phải bỏ nó (JavaScriptCore là mô phạm về ngăn xếp) và tôi không muốn mạo hiểm với cơn thịnh nộ của họ nên tôi quyết định không đề cập đến nó.

Bạn nghĩ sao? Là JavaScript có nghĩa là một luồng đơn, và nó có nên được để lại một mình không? Tại sao mọi người chống lại ý tưởng về thời gian chạy JavaScript đồng thời?

Chỉnh sửa: Dự án hiện đã có trên GitHub , hãy tự mình thử nghiệm và cho tôi biết bạn nghĩ gì.

Sau đây là hình ảnh về những lời hứa chạy trên tất cả các lõi CPU song song không có sự tranh chấp:

1) Đa luồng là vô cùng khó khăn, và thật không may là cách bạn đã trình bày ý tưởng này cho đến nay ngụ ý rằng bạn đang đánh giá thấp mức độ khó của nó.

Hiện tại, có vẻ như bạn chỉ đơn giản là "thêm chủ đề" vào ngôn ngữ và lo lắng về cách làm cho nó chính xác và hiệu suất sau này. Đặc biệt:

nếu hai tác vụ cố gắng truy cập đồng thời một biến thì nó được đánh dấu nguyên tử và chúng tranh giành quyền truy cập.
...
Tôi đồng ý rằng các biến nguyên tử sẽ không giải quyết được mọi thứ, nhưng làm việc trên một giải pháp cho vấn đề đồng bộ hóa là mục tiêu tiếp theo của tôi.

Thêm chủ đề vào Javascript mà không có "giải pháp cho vấn đề đồng bộ hóa" sẽ giống như thêm số nguyên vào Javascript mà không có "giải pháp cho vấn đề bổ sung". Nó rất cơ bản đối với bản chất của vấn đề đến nỗi về cơ bản không có vấn đề gì để thảo luận liệu đa luồng có đáng để thêm vào hay không mà không có giải pháp cụ thể nào, cho dù chúng ta có muốn nó đến mức nào.

Thêm vào đó, làm cho tất cả các biến nguyên tử là loại điều có khả năng làm cho một chương trình đa luồng hoạt động kém hơn so với đối tác đơn lẻ của nó, điều này càng quan trọng hơn khi thực sự kiểm tra hiệu suất trên các chương trình thực tế hơn và xem liệu bạn có đạt được gì hay không.

Tôi cũng không rõ liệu bạn đang cố gắng giấu các luồng khỏi lập trình viên node.js hay nếu bạn dự định phơi bày chúng vào một lúc nào đó, thực sự tạo ra một phương ngữ Javascript mới cho lập trình đa luồng. Cả hai tùy chọn đều có khả năng thú vị, nhưng có vẻ như bạn thậm chí chưa quyết định bạn đang nhắm đến cái nào.

Vì vậy, hiện tại, bạn đang yêu cầu các lập trình viên xem xét chuyển đổi từ môi trường đơn lẻ sang môi trường đa luồng hoàn toàn mới, không có giải pháp cho vấn đề đồng bộ hóa và không có bằng chứng nào cải thiện hiệu suất trong thế giới thực và dường như không có kế hoạch giải quyết các vấn đề đó.

Đó có lẽ là lý do tại sao mọi người không coi trọng bạn.

2) Sự đơn giản và mạnh mẽ của vòng lặp sự kiện duy nhất là một lợi thế rất lớn .

Các lập trình viên Javascript biết rằng ngôn ngữ Javascript "an toàn" khỏi các điều kiện chủng tộc và các lỗi cực kỳ quỷ quyệt khác gây ra tất cả các chương trình đa luồng thực sự. Việc họ cần những lý lẽ mạnh mẽ để thuyết phục họ từ bỏ rằng sự an toàn không khiến họ trở nên khép kín, điều đó khiến họ có trách nhiệm.

Trừ khi bạn có thể giữ được sự an toàn đó bằng cách nào đó, bất kỳ ai muốn chuyển sang node.js đa luồng có lẽ tốt hơn nên chuyển sang ngôn ngữ như Go được thiết kế từ đầu cho các ứng dụng đa luồng.

3) Javascript đã hỗ trợ "luồng nền" (WebWorkers) và lập trình không đồng bộ mà không trực tiếp đưa ra quản lý luồng cho lập trình viên.

Các tính năng này đã giải quyết rất nhiều trường hợp sử dụng phổ biến ảnh hưởng đến các lập trình viên Javascript trong thế giới thực, mà không từ bỏ sự an toàn của vòng lặp sự kiện.

Bạn có bất kỳ trường hợp sử dụng cụ thể nào mà các tính năng này không giải quyết được không và các lập trình viên Javascript muốn có giải pháp cho? Nếu vậy, sẽ là một ý tưởng tốt để trình bày node.js đa luồng của bạn trong ngữ cảnh của trường hợp sử dụng cụ thể đó.

PS Điều gì sẽ thuyết phục tôi thử chuyển sang triển khai node.js đa luồng?

Viết một chương trình không tầm thường trong Javascript / node.js mà bạn nghĩ sẽ được hưởng lợi từ đa luồng chính hãng. Thực hiện kiểm tra hiệu suất trên chương trình mẫu này trong nút bình thường và nút đa luồng của bạn. Cho tôi thấy rằng phiên bản của bạn cải thiện hiệu năng thời gian chạy, khả năng phản hồi và sử dụng nhiều lõi ở một mức độ đáng kể, mà không đưa ra bất kỳ lỗi hoặc mất ổn định nào.

Khi bạn đã thực hiện điều đó, tôi nghĩ bạn sẽ thấy mọi người quan tâm nhiều hơn đến ý tưởng này.

Chỉ cần đoán ở đây để chứng minh một vấn đề trong cách tiếp cận của bạn. Tôi không thể kiểm tra nó so với triển khai thực tế vì không có liên kết ở bất cứ đâu ...

Tôi muốn nói rằng đó là vì các bất biến không phải luôn luôn được biểu thị bằng giá trị của một biến và 'một biến' không đủ để là phạm vi của khóa trong trường hợp chung. Ví dụ: hãy tưởng tượng chúng ta có một bất biến a+b = 0(số dư của một ngân hàng có hai tài khoản). Hai hàm bên dưới đảm bảo rằng bất biến luôn được giữ ở cuối mỗi hàm (đơn vị thực hiện trong JS đơn luồng).

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

Bây giờ, trong thế giới đa luồng của bạn, điều gì xảy ra khi hai luồng thực thi withdrawvà depositcùng một lúc? Cảm ơn, Murphy ...

(Bạn có thể có mã xử lý + = và - = đặc biệt, nhưng điều đó không có ích. Đến một lúc nào đó, bạn sẽ có trạng thái cục bộ trong một hàm và không có cách nào để 'khóa' hai biến cùng một lúc bị vi phạm.)

EDIT: Nếu mã của bạn tương đương về mặt ngữ nghĩa với mã Go tại https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a , nhận xét của tôi là chính xác ;-)

Một thập kỷ trước, Brendan Eich (người phát minh ra JavaScript) đã viết một bài luận có tên là Suck , đây chắc chắn là một trong số ít tài liệu kinh điển về thần thoại thiết kế của JavaScript.

Liệu nó có đúng hay không là một câu hỏi khác, nhưng tôi nghĩ nó có ảnh hưởng lớn đến cách cộng đồng JavaScript nghĩ về sự tương tranh.

Truy cập nguyên tử không chuyển thành hành vi an toàn chủ đề.

Một ví dụ là khi cấu trúc dữ liệu toàn cầu cần phải không hợp lệ trong quá trình cập nhật như làm lại một hashmap (ví dụ khi thêm một thuộc tính vào một đối tượng) hoặc sắp xếp một mảng toàn cục. Trong thời gian đó, bạn không thể cho phép bất kỳ luồng nào khác truy cập vào biến. Điều này về cơ bản có nghĩa là bạn cần phát hiện toàn bộ chu trình đọc-cập nhật-ghi và khóa nó. Nếu bản cập nhật không tầm thường sẽ dẫn đến việc tạm dừng lãnh thổ vấn đề.

Javascript đã được phân luồng đơn và hộp cát ngay từ đầu và tất cả các mã được viết với các giả định này trong tâm trí.

Điều này có một lợi thế lớn liên quan đến các bối cảnh bị cô lập và cho phép 2 bối cảnh riêng biệt chạy trong các luồng khác nhau. Tôi cũng có nghĩa là mọi người viết javascript không cần phải biết cách xử lý các điều kiện chủng tộc và các pitfals đa luồng khác.

Là cách tiếp cận của bạn sẽ cải thiện đáng kể hiệu suất?

Nghi ngờ. Bạn thực sự cần phải chứng minh điều này.

Là cách tiếp cận của bạn sẽ làm cho nó dễ dàng hơn / nhanh hơn để viết mã?

Chắc chắn là không, mã đa luồng khó gấp nhiều lần so với mã đơn.

Là cách tiếp cận của bạn sẽ mạnh mẽ hơn?

Bế tắc, điều kiện chủng tộc, vv là một cơn ác mộng để khắc phục.

Việc triển khai của bạn không chỉ là giới thiệu đồng thời, mà là giới thiệu một cách cụ thể để thực hiện đồng thời tức là đồng thời theo trạng thái có thể thay đổi được chia sẻ. Trong suốt lịch sử, con người đã sử dụng loại đồng thời này và điều này dẫn đến nhiều loại vấn đề. Tất nhiên, bạn có thể tạo các chương trình đơn giản hoạt động hoàn hảo với việc sử dụng đồng thời trạng thái có thể thay đổi được chia sẻ nhưng thử nghiệm thực sự của bất kỳ cơ chế nào không phải là những gì nó có thể làm mà có thể mở rộng khi chương trình trở nên phức tạp và ngày càng có nhiều tính năng được thêm vào chương trình. Hãy nhớ rằng phần mềm không phải là một thứ tĩnh mà bạn xây dựng một lần và được thực hiện với nó, thay vào đó nó tiếp tục phát triển theo thời gian và nếu bất kỳ cơ chế hoặc khái niệm nào có thể '

Bạn có thể xem xét các mô hình đồng thời khác (ví dụ: truyền tin nhắn) để giúp bạn tìm ra loại lợi ích mà các mô hình đó cung cấp.

Điều này là cần thiết. Việc thiếu một cơ chế đồng thời ở mức thấp trong nút js sẽ hạn chế các ứng dụng của nó trong các lĩnh vực như toán học và tin sinh học, v.v ... Bên cạnh đó, đồng thời với các luồng không nhất thiết phải xung đột với mô hình đồng thời mặc định được sử dụng trong nút. Có những ngữ nghĩa nổi tiếng để phân luồng trong một môi trường có vòng lặp sự kiện chính, chẳng hạn như khung ui (và nodejs) và tho chúng chắc chắn quá phức tạp đối với hầu hết các tình huống chúng vẫn sử dụng hợp lệ.

Chắc chắn, ứng dụng web trung bình của bạn sẽ không yêu cầu chủ đề, nhưng hãy thử làm bất cứ điều gì ít thông thường hơn và việc thiếu tính nguyên thủy đồng thời ở mức độ thấp sẽ nhanh chóng đưa bạn đến một thứ khác cung cấp nó.

Tôi thực sự tin rằng đó là vì đó là một ý tưởng khác biệt và mạnh mẽ. Bạn đang đi ngược lại các hệ thống niềm tin. Công cụ trở nên được chấp nhận hoặc phổ biến thông qua mạng ảnh hưởng không dựa trên công đức. Ngoài ra không ai muốn thích nghi với một ngăn xếp mới. Mọi người tự động từ chối những thứ quá khác biệt.

Nếu bạn có thể đưa ra một cách để biến nó thành một mô-đun npm thông thường nghe có vẻ không ổn, thì bạn có thể sẽ có một số người sử dụng nó.