T.Dark
Senior Member
hình như click event nó cũng là webapiDùng cái setTimeOut là là đã sử dụng webAPI r mai fen
Cứ cho một sự kiện click r vòng lặp 1000000 r log ra kq là đc r mà
via theNEXTvoz for iPhone
hình như click event nó cũng là webapiDùng cái setTimeOut là là đã sử dụng webAPI r mai fen
Cứ cho một sự kiện click r vòng lặp 1000000 r log ra kq là đc r mà
via theNEXTvoz for iPhone
thì tôi có nói setTimeOut là của JS spec đâu. Của thằng nào cũng ko quan trọng ko liên quann đến vd trên
Nhưng ý là demo cái tư tưởng bác xài cái làm j trong function truyền cho setTimeout thì cũng ko dừng đc cái loop kia.

Xét cho kỹ thì làm j có cách nào chứng minh rõ ràng đc. Vì cơ bản đâu có thực sự multithread đâu. Nên ko làm kiểu busy event loop thì còn cách nào khác?Ví dụ của thím mình thấy liên quan đến event loop và call stack nhiều hơn, vì call stack của thím luôn ko rỗng nên cái đoạn code trong settimeout cứ ở trong queue và ko bao giờ dc đẩy sang call stack. Còn muốn chứng minh single thread ở browser thì chắc đơn giản là viết 1 cái alert và 1 đống code ở dưới cho chạy, cái alert sẽ block browser và đoạn code ở dưới chỉ chạy tiếp khi đóng cái alert, ko biết có đúng ko nhỉ![]()
Theo bác này nói thì JS nó không có mutexes/locks nhưng vẫn đảm bảo được tính đúng/toàn vẹn của dữ liệu nên nó là Single Thead.This doesn't strictly prove that JavaScript is only run on a single thread, because concurrency is very subtle.
In C++, this example (using, e.g., std::thread to start a second thread) might hang because there's no explicit synchronization of the loop variable, even though C++ can run on multiple threads
In Go, this example (using go to start a goroutines) might hang because the thread scheduler isn't fair, and might never preempt the loop without a wait in it.
Busy waiting is a bad idea in any language -- and it's why you should basically never notice that JavaScript is single threaded. The only way it should really affect your code is that you don't need mutexes/locks to protect 'critical sections' where you need to make many updates at once to be consistent

vậy nó là đa luồng = multithread rồi còn gì nữa (chém gió bên lề tí thôi chứ mình chỉ vào đây hóng hớt tí kiến thức, mấy cái này mình cũng chưa đào sâu tìm hiểu bao giờsao em chưa nghe ai bảo bao giờ nhỉ. JS nhìn nó như multithread, nhưng thật ra chỉ có đúng 1 thread thôi, trong thread đó nó có 1 luồng chính, và các luồng phụ xử lý các worker, script.... (kinh nghiệm cá nhân, các thím tay to có biết gì thì sửa giúp em![]()
)
)Kiểu như alert phải ko thím, dù nó đc kích hoạt ở bất cứ từ thread nào (lúc này ko cần quan tâm là nó có bao nhiêu thread) nào thì js cũng đều bị block chờ user tắt cửa sổ alert để chạy tiếp => nó là single threadLúc còn làm cho cty, cũng hay được đi phỏng vấn cùng leader. Đã pv khá nhiều ứng viên cho vị trí Js/Nodejs, hay hỏi một câu "Lấy một ví dụ để minh họa Js chạy trên môi trường trình duyệt web chrome là single thread", mới gặp được 1 cậu trả lời khá ưng, còn lại thì hơi mung lung.
busy wait là ví dụ không hợp lý, dù chỉ một thread nhiều ngôn ngữ nó vẫn có task scheduler để chạy nhiều task một lúc dù là một thread (google concurrent vs parallel). nếu javascript bị busy wait thì chỉ chứng tỏ được cái event loop của js kém tắm thôi :/
vậy nó là đa luồng = multithread rồi còn gì nữa (chém gió bên lề tí thôi chứ mình chỉ vào đây hóng hớt tí kiến thức, mấy cái này mình cũng chưa đào sâu tìm hiểu bao giờ![]()
)

làm như thế nào thì bạn có thể tham khảo tại sao OS (hoặc dễ hình dung hơn là mấy cái VPS giá rẻ) dùng một CPU vẫn chạy được đa tác vụ.Giả sử task dó là CPU bound và ko ngưng luôn ( như while(true) và tính toán ko có chờ IO) thì sao thím.
Mình thấy có thằng nào làm thông minh hơn đâu. nó đều block toàn bộ cái thread đang xử lý cái task đó. JS chỉ 1 thread nên tạch, dù trong event loop còn event cần xử.
làm như thế nào thì bạn có thể tham khảo tại sao OS (hoặc dễ hình dung hơn là mấy cái VPS giá rẻ) dùng một CPU vẫn chạy được đa tác vụ.
giải thích qua loa thì một chương trình đang chạy nó sẽ break thành các "chunk", nó chạy hết chunk này sẽ chạy chunk khác. tất nhiên việc đổi chunk đang chạy sang chunk khác đồng nghĩa với việc xoá hết cache nạp lại + copy data các kiểu, giảm performance đáng kể, implementation cũng phức tạp, cho nên nhiều ngôn ngữ họ thấy không cần cho nên không làm thôi.
cơ mà không phải là không có, BEAM (elarng/elixir) là một thằng tiêu biểu trong vụ tạo mấy "chunk" này cực ngắn, cho nên các bạn thường nghe nói cái BEAM này latency rất thấp, nhưng hiệu năng lại kém mấy thằng khác là vì thế. trong elixir/erlang thì dù bạn có cho chạy vòng for từ 1 tới 10^100 thì các task khác vẫn chạy bình thường, dù chỉ một CPU.

cái multi-threaded ở đây là người ta nói cpu thread, tức là ngôn ngữ này phải cho phép tận dụng tất cả các thread của cpu (aka có thể chạy 100% cpu), chứ đếch phải là tao dùng thêm một thread nữa chạy GC, một thread nữa chạy event loop, thế là tao cũng là multithread.
lưu ý lần nữa là cái vụ này nó phải được provide ở mức độ ngôn ngữ (runtime, stdlib etc), chứ ví dụ như ruby cái parallel gem cũng chạy theo số cores/threads được nhưng nó phải dùng marshal để giao tiếp giữa các thread thì cũng bằng nhau.




Js single thread thôi bác, cái worker nó giống kiểu tạo process khác hơn. Các dữ liệu dùng chung thì phải truyền qua lại chứ không access trực tiếp đượcRồi bác cho em hỏi js là multi hay single? Như bác nói thì thread chính xử lý là single![]()
vl. cái videos kinh điển rồi
Đó là lý thuyết thôi, còn thực tế thì spec và impl của lang đôi khi đi liền với nhau quan trọng là cái spec đó nó rộng đến đâu.chả thấy liên quan gì nhau. javascript là ngôn ngữ lập trình. đa luồng/đa tiến trình là cách thực thi chương trình. nói javascript là đơn luồng sai; nói javascript là đa luồng sai nốt. nói thế khác gì bảo ngôn ngữ lập trình là cách thực thi chương trình. ông anh ở công tỹ não bò rồi.
Đó là lý thuyết thôi, còn thực tế thì spec và impl của lang đôi khi đi liền với nhau quan trọng là cái spec đó nó rộng đến đâu.
Ví dụ nhé:
https://docs.oracle.com/javase/specs/jls/se14/html/jls-17.html
https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency:_goroutines_and_channels
https://erlang.org/doc/reference_manual/processes.html
. Nếu có 2 người dùng đăng nhập lần lượt đồng thời
(liền nhau, cách nhau không đáng kể), người đăng nhập thứ 2 sẽ phải đợi bao lâu để có thể đăng nhập?", sau đó sẽ có vài câu tại sao nữa, nên bạn nào lanh lợi thì nên giải thích luôn (nếu bạn chắc chắn đoán được câu hỏi tiếp theo). Phiên phiến thôi, chính xác tới từng "phút" là được rồi.