Tại sao nodejs là single thread

thảo luận - Javascript có thực sự là single thread ? | theNEXTvoz

teeeeeeeee

T.Dark

JS là single thread nhé, tìm hiểu về event loop

zizz

teeeeeeeee

EM biết mà thím nhưng mà có ý kiến cho là JS giờ đã support multithread r thím

zzchaolegionzz

Cái event loop rõ ràng là single thread, nhưng các task async chẳng phải đang chạy ở thread khác sao, nó chỉ hook up lại với cái event loop sau khi đã chạy xong. Thôi có cái video + code demo cho dễ hiểu đây:

zizz

EM biết mà thím nhưng mà có ý kiến cho là JS giờ đã support multithread r thím

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

Tại sao nodejs là single thread
Tại sao nodejs là single thread
)

Nipin

thằng nào bảo js là multithread thì cứ vả vào mồm.
js không cung cấp cái mechanism nào cho việc mutithread cả, ví dụ mutex.
thư viện ngoài không nói.

Country Daughter

js single thread, còn bên dưới nó chạy multithread ko thì là câu chuyển khác

cugiametruyen85

Single threaded là đang nói ở khía cạnh của developer, còn runtime thì liên quan gì. Giống như nói java là managed language thì đâu có nghĩa cái jvm cũng managed nốt.
Mà anh nào bảo JS support multithread thì cũng đếch có nghĩa nó support tốt bằng mấy thằng khác. Cái mớ Web Workers đúng nghĩa khổ dâm.
Nói JS hỗ trợ multithread dựa trên Web Worker thì cũng gần đúng bởi vì hầu hết các implement của nó đều hỗ trợ web worker.

WebAPI này được cung cấp bởi browser và dùng để chạy các đoạn code JS chứ không phải là bản thân JS đã support multithread

Cái bạn muốn nói là Ecmascript, còn nói JS nghĩa là nói đến 1 tập con impl như V8, JavaScriptCore, spider các kiểu...

Last edited: Aug 22, 2020

rauma01

Lú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.

Nipin

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.

panoti

Engine để chạy JS thì single thread, còn cái web worker theo đặc tả phải chạy trên môi trường độc lập trên Thread hoặc Process khác.

Sent using vozFApp

zzchaolegionzz

Lú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.

Hóng câu trả lời

Tại sao nodejs là single thread
chia sẻ đi thím.

BaronNashor

Mấy bác code JS lâu có tự tin trả lời mấy khái niệm cơ bản của JS như
1. Hoisting
2. Scope
3. Stack
4. this keyword

không nhỉ? Em mới nhảy sang JS code code thì cũng code được thôi mà nhiều khái niệm chưa phân biệt được rõ khá mơ hồ

T.Dark

Mấy bác code JS lâu có tự tin trả lời mấy khái niệm cơ bản của JS như
1. Hoisting
2. Scope
3. Stack
4. this keyword

không nhỉ? Em mới nhảy sang JS code code thì cũng code được thôi mà nhiều khái niệm chưa phân biệt được rõ khá mơ hồ

Bảo hỏi trả lời luôn thì cũng chưa chắc

Tại sao nodejs là single thread
trước khi phỏng vấn vẫn phải lướt lướt qua mấy cái

zulu

Lú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.

Dễ mà ta.
Dưa trên cơ chế event loop của nó, Khai báo global với isRunning gán = true
1. setup 1 cái setTimeout sau 3s bắt đầu, để gán lại cái isRunning = false.
2. tôi tạo 1 cái infinity loop while(isRunning) . Và thân loop in dòng j đó ra coi chơi.
3. Nhưng rất tiếc là ko stop đc cái loop trên.

teeeeeeeee

Dễ mà ta.
Dưa trên cơ chế event loop của nó, Khai báo global với isRunning gán = true
1. setup 1 cái setTimeout sau 3s bắt đầu, để gán lại cái isRunning = false.
2. tôi tạo 1 cái infinity loop while(isRunning) . Và thân loop in dòng j đó ra coi chơi.
3. Nhưng rất tiếc là ko stop đc cái loop trên.

Dù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

zulu

Dù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.

teeeeeeeee

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.

Đề bài của thím kia chỉ là demo để thấy chạy singlethread thôi mà fen

via theNEXTvoz for iPhone

T.Dark

Dù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à webapi

22mario9x

Tại sao nodejs là single thread

kazimhung559

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.

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ỉ

Tại sao nodejs là single thread

zulu

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ỉ

Tại sao nodejs là single thread

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?

Rõ ràng là js nó execute các event trong event loop tuần tự . Chứ model của mấy thằng khác như java có execution context. Job đc submit vô và các thread trong pool của nó lập lịch xử các job đó.

Còn cách của thím cũng có rõ ràng j đâu? Vì alert là web api

via nextVOZ for iPhone

22mario9x

https://dev.to/rajajaganathan/prove-that-javascript-runs-in-a-single-thread-1d7n

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

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.
Cái này giống như định lý không cần chứng minh

Tại sao nodejs là single thread

Nipin

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 :/

hgdom

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

Tại sao nodejs là single thread
Tại sao nodejs là single thread
)

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ờ

Tại sao nodejs là single thread
Tại sao nodejs là single thread
)

hgdom

Lú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.

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 thread

zulu

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 :/

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ử.

zizz

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ờ

Tại sao nodejs là single thread
Tại sao nodejs là single thread
)

luồng em đang nói là luồng của node, còn luồng về cpu là khác bác ơi

Tại sao nodejs là single thread

Gửi từ Điện thoại ghẻ lướt voz bằng vozFApp

Nipin

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.

Nipin

à mà não rút, thực ra chỉ cần ví dụ cái goroutine là được :v
hoặc mấy ngôn ngữ khác có fiber cũng tương tự :v

TrangTraiCoDon

Js vẫn là single thread,
Còn webworker (browser), Worker (nodejs) để tạo thread mới chủ yếu xử lý công việc nặng nhọc
Còn bản thân js vẫn single thread, ông đúng và thằng trên cty sai

zulu

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.

ok bác, cái này thì e hiểu chỉ vì nhiều ngôn ngữ mình biết ko có implement kiểu này. Nên hỏi bác xem có thằng nào làm.

kevin.leptons

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.

Tại sao nodejs là single thread

voiconoi

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.

Rồ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

Tại sao nodejs là single thread
Tại sao nodejs là single thread
Tại sao nodejs là single thread
Tại sao nodejs là single thread

kyo_pyro

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 được

rauma01

Có mấy bác nói có ý đúng về việc lấy ví dụ về vụ js là single threaded.

Mấy bác lấy ví dụ sync code kiểu như: white(true), alert()... là chưa chuẩn đâu nhé, cái này thể hiện code được chạy tuần tự thôi, api alert() là hàm đồng bộ, trong ngôn ngữ Java cũng không thiếu hàm kiểu này: .readLine() (không nhớ lắm, chờ nhận một tín hiệu từ bàn phím).

Trong js bạn không thể lấy được một ví dụ mà trong đó có nhiều hơn một "luồng" cùng truy cập vào một biến. Kiểu như một "luồng" thêm dữ liệu vào mảng, "luồng" khác "pop" dữ liệu từ mảng đó ra.

Như bác này có nói, js không được impl để làm việc ở trên với tư tưởng "multi threaded"

Tiện đây cũng có một câu khác, câu này được hỏi để phân cấp "trên" fresher hay không? Thật khó để ngay lập tức phân loại được một ứng viên, nhưng mình nghĩ với câu này là khá ok:

"JS là single threaded. Có 2 api để đăng nhập [1 bằng js chạy trên nodejs (express), 1 bằng Java với spring bot], người dùng sẽ gửi lên user/pass, api service truy vấn tới database để trả ra kết quả đăng nhập thành công hay không?. Database là mysql, truy vấn login luôn mất 10 phút

Tại sao nodejs là single thread
. Nếu có 2 người dùng đăng nhập lần lượt đồng thời
Tại sao nodejs là single thread
(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.

soihoang

đâu cần đợi đâu, truy vấn là IO mà thằng js/node là non-block, còn java thì multi-thread(vẫn có non-blocking IO), còn lại thì coi db nó xử lý concurrency thế nào.

zhukov

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.

Mấy cái này như coroutine . Nó ko xoá cache đâu thím ( ko chính xác ). Nó dùng cơ chế context sw. Sao lưu khôi phục các thanh ghi trên cpu. Bên linux nó tuân theo mấy cái tiêu chuẩn ABI GÌ gì đó. Đại loại như đối số hàm sẽ ở rsi rdi ... Rsp rbp ...r11 ->r14 phải khôi phục sau khi sử dụng.
Thành ra nó có tác dụng như mutithread nhưng chỉ trên 1 process. Nó khác multithread thật ở chỗ. Chi phí cpu cho vụ context sw ít hơn nhiều so vs context của os. Cơ mà nó vẫn có nhược điểm là cần chuyển đổi ngữ cảnh. Và có rất nhiều regisster ko được backup. Sẽ hạn chế tính toán phức tạp kha khá.
Nó chỉ phù hợp cho nhũng nhiệm vụ kiểu io nhiều. Chứ còn lại thấy ko hợp lắm.
Vụ js chơi kieeu bài loop event rất hiện đại cơ mà vụ call back thì phát hoảng. Chưa kể thằng đằng sau nó Epoll có mấy cái bug chủ chuối vãi. Có một lão ched tơi tả vụ nầy.... Chém gió tí.

Nipin

Mấy cái này như coroutine . Nó ko xoá cache đâu thím ( ko chính xác ). Nó dùng cơ chế context sw. Sao lưu khôi phục các thanh ghi trên cpu. Bên linux nó tuân theo mấy cái tiêu chuẩn ABI GÌ gì đó. Đại loại như đối số hàm sẽ ở rsi rdi ... Rsp rbp ...r11 ->r14 phải khôi phục sau khi sử dụng.
Thành ra nó có tác dụng như mutithread nhưng chỉ trên 1 process. Nó khác multithread thật ở chỗ. Chi phí cpu cho vụ context sw ít hơn nhiều so vs context của os. Cơ mà nó vẫn có nhược điểm là cần chuyển đổi ngữ cảnh. Và có rất nhiều regisster ko được backup. Sẽ hạn chế tính toán phức tạp kha khá.
Nó chỉ phù hợp cho nhũng nhiệm vụ kiểu io nhiều. Chứ còn lại thấy ko hợp lắm.
Vụ js chơi kieeu bài loop event rất hiện đại cơ mà vụ call back thì phát hoảng. Chưa kể thằng đằng sau nó Epoll có mấy cái bug chủ chuối vãi. Có một lão ched tơi tả vụ nầy.... Chém gió tí.

cache nó mang nhiều nghĩa lắm bạn ơi :v
edit: ờ ý tôi là nhiều kiểu cache, từ cache opcode, l1 l2 l3 cache rồi thì đủ kiểu. mỗi lần context switch sẽ involve một đống thứ.

hồi trước cũng đọc một vài bài báo về vấn đề này cơ mà giờ quên mất rồi, đợi lúc nào tìm lại :v

Supersoyx

Cái event loop rõ ràng là single thread, nhưng các task async chẳng phải đang chạy ở thread khác sao, nó chỉ hook up lại với cái event loop sau khi đã chạy xong. Thôi có cái video + code demo cho dễ hiểu đây:

Async không phải multthread nhé. Chỉ có web work chạy nền thực sự nhưng web work không được phép truy cập DOM object nên cũng hạn chế rồi

bribnt

Mấy cái này như coroutine . Nó ko xoá cache đâu thím ( ko chính xác ). Nó dùng cơ chế context sw. Sao lưu khôi phục các thanh ghi trên cpu. Bên linux nó tuân theo mấy cái tiêu chuẩn ABI GÌ gì đó. Đại loại như đối số hàm sẽ ở rsi rdi ... Rsp rbp ...r11 ->r14 phải khôi phục sau khi sử dụng.
Thành ra nó có tác dụng như mutithread nhưng chỉ trên 1 process. Nó khác multithread thật ở chỗ. Chi phí cpu cho vụ context sw ít hơn nhiều so vs context của os. Cơ mà nó vẫn có nhược điểm là cần chuyển đổi ngữ cảnh. Và có rất nhiều regisster ko được backup. Sẽ hạn chế tính toán phức tạp kha khá.
Nó chỉ phù hợp cho nhũng nhiệm vụ kiểu io nhiều. Chứ còn lại thấy ko hợp lắm.
Vụ js chơi kieeu bài loop event rất hiện đại cơ mà vụ call back thì phát hoảng. Chưa kể thằng đằng sau nó Epoll có mấy cái bug chủ chuối vãi. Có một lão ched tơi tả vụ nầy.... Chém gió tí.


cache nó mang nhiều nghĩa lắm bạn ơi :v
edit: ờ ý tôi là nhiều kiểu cache, từ cache opcode, l1 l2 l3 cache rồi thì đủ kiểu. mỗi lần context switch sẽ involve một đống thứ.

hồi trước cũng đọc một vài bài báo về vấn đề này cơ mà giờ quên mất rồi, đợi lúc nào tìm lại :v

Context switch ở mức process thì có thể sẽ phải flush cache, tùy trường hợp.

Lý do là vì ứng dụng sử dụng địa chỉ bộ nhớ ảo. Nên hoàn toàn có thể phát sinh trường hợp 2 process khác nhau sử dụng chung địa chỉ ảo nhưng thực chất là trỏ đến địa chỉ vật lý khác nhau, hoặc ngược lại là 2 process dùng địa chỉ ảo khác nhau nhưng lại chung địa chỉ vật lý.

Khi đó nếu như cache được tag bằng địa chỉ ảo thì bắt buộc phải flush khi context switch, nếu không sẽ dẫn đến sai lêch. Điều này là khá phổ biến ở cache L1 vì tag địa chỉ ảo nhanh, không cần phải pagewalk để lấy địa chỉ vật lý. L2 và L3 thì thường tag bằng địa chỉ vật lý vì yêu cầu về latency không quá cao như L1, với lại flush L2 với L3 thì tốn chu kỳ CPU (do kích thước nó lớn) và ảnh hưởng đến hiệu năng nhiều ứng dụng khác.

Có một giải pháp đỡ phải flush L1 là gắn thêm pid vào tag để phân biệt, nhưng cái này cũng tùy CPU.

Còn "context switch" theo kiểu async thì chắc không cần flush, vì vẫn chung một thread, chung không gian bộ nhớ ảo.

motophankhoilon

Có mấy bác nói có ý đúng về việc lấy ví dụ về vụ js là single threaded.

Mấy bác lấy ví dụ sync code kiểu như: white(true), alert()... là chưa chuẩn đâu nhé, cái này thể hiện code được chạy tuần tự thôi, api alert() là hàm đồng bộ, trong ngôn ngữ Java cũng không thiếu hàm kiểu này: .readLine() (không nhớ lắm, chờ nhận một tín hiệu từ bàn phím).

Trong js bạn không thể lấy được một ví dụ mà trong đó có nhiều hơn một "luồng" cùng truy cập vào một biến. Kiểu như một "luồng" thêm dữ liệu vào mảng, "luồng" khác "pop" dữ liệu từ mảng đó ra.

Như bác này có nói, js không được impl để làm việc ở trên với tư tưởng "multi threaded"

Tiện đây cũng có một câu khác, câu này được hỏi để phân cấp "trên" fresher hay không? Thật khó để ngay lập tức phân loại được một ứng viên, nhưng mình nghĩ với câu này là khá ok:

"JS là single threaded. Có 2 api để đăng nhập [1 bằng js chạy trên nodejs (express), 1 bằng Java với spring bot], người dùng sẽ gửi lên user/pass, api service truy vấn tới database để trả ra kết quả đăng nhập thành công hay không?. Database là mysql, truy vấn login luôn mất 10 phút

Tại sao nodejs là single thread
. Nếu có 2 người dùng đăng nhập lần lượt đồng thời
Tại sao nodejs là single thread
(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.

Cái đó phải tùy vào thằng mariadb nó lock lại bao lâu để chờ read ra chứ, k thì sẽ dính race condition sao

zhukov

Mình đang băn kho

Context switch ở mức process thì có thể sẽ phải flush cache, tùy trường hợp.

Lý do là vì ứng dụng sử dụng địa chỉ bộ nhớ ảo. Nên hoàn toàn có thể phát sinh trường hợp 2 process khác nhau sử dụng chung địa chỉ ảo nhưng thực chất là trỏ đến địa chỉ vật lý khác nhau, hoặc ngược lại là 2 process dùng địa chỉ ảo khác nhau nhưng lại chung địa chỉ vật lý.

Khi đó nếu như cache được tag bằng địa chỉ ảo thì bắt buộc phải flush khi context switch, nếu không sẽ dẫn đến sai lêch. Điều này là khá phổ biến ở cache L1 vì tag địa chỉ ảo nhanh, không cần phải pagewalk để lấy địa chỉ vật lý. L2 và L3 thì thường tag bằng địa chỉ vật lý vì yêu cầu về latency không quá cao như L1, với lại flush L2 với L3 thì tốn chu kỳ CPU (do kích thước nó lớn) và ảnh hưởng đến hiệu năng nhiều ứng dụng khác.

Có một giải pháp đỡ phải flush L1 là gắn thêm pid vào tag để phân biệt, nhưng cái này cũng tùy CPU.

Còn "context switch" theo kiểu async thì chắc không cần flush, vì vẫn chung một thread, chung không gian bộ nhớ ảo.

Mình đang nghic băn khoăn vụ stack mem của coroutine. Đại loại ví dụ hàm A càng ngày càng sử dụng nhiều stack ( tăng kích thước nhớ trên stack ). Dẫn đến một lúc nào đó nó sẽ tràn vào vùng stack của hàm B. Vấn đề đọc mã nhiều lib coroutine thấy nó chỉ lưu trữ- khôi phục rsp vs rbp. Chứ ko hề thực hiện cho tất cả đoạn stack của hàm A.
Đang đọc vấn đề này đang tìm biện pháp xử lý giải quyết. Đang định làm một lib coroutine riêng. Đọc mấy bài trên blog bọn Tây cũng ko nhiều. Tụi nó nói phải làm lại trình dịch ....Nghe sao thấy oải. Ý nói vụ này phải được quy về một tính năng ngôn ngữ. Chứ ko thể dùng lib. Cá nhân dang dùng mấy libco cảm thấy có nhiều chỗ chạy ko hài lòng lắm. Cần tùy chỉnh thêm ....
Thím có cao kiến , xin cho tí ý kiến nào

Tại sao nodejs là single thread

L1f3 ver 2

Mình đang băn kho

Mình đang nghic băn khoăn vụ stack mem của coroutine. Đại loại ví dụ hàm A càng ngày càng sử dụng nhiều stack ( tăng kích thước nhớ trên stack ). Dẫn đến một lúc nào đó nó sẽ tràn vào vùng stack của hàm B. Vấn đề đọc mã nhiều lib coroutine thấy nó chỉ lưu trữ- khôi phục rsp vs rbp. Chứ ko hề thực hiện cho tất cả đoạn stack của hàm A.
Đang đọc vấn đề này đang tìm biện pháp xử lý giải quyết. Đang định làm một lib coroutine riêng. Đọc mấy bài trên blog bọn Tây cũng ko nhiều. Tụi nó nói phải làm lại trình dịch ....Nghe sao thấy oải. Ý nói vụ này phải được quy về một tính năng ngôn ngữ. Chứ ko thể dùng lib. Cá nhân dang dùng mấy libco cảm thấy có nhiều chỗ chạy ko hài lòng lắm. Cần tùy chỉnh thêm ....
Thím có cao kiến , xin cho tí ý kiến nào

Tại sao nodejs là single thread

Em ko hiểu ý của thím. Nếu A và B cùng 1 thread thì sẽ ko bao h xảy ra trường hợp đó vì rsp giảm dần sau mỗi lần call hàm. Còn nếu 2 hàn nằm ở 2 thrad khác nhau thì cũng ko bao h stack va vào nhau cả vì 2 thread riêng sẽ tạo ra 2 stack mem khác nhau chứ ko phải là 2 frame khác nhau trên cùng 1 stack

KiethA

Hiểu đơn giản single thread chỉ là xử lý đồng thời trên một thread. Còn multi thread là 1 process có nhiều thread, mỗi thread độc lập xử lý.

bribnt

Mình đang băn kho

Mình đang nghic băn khoăn vụ stack mem của coroutine. Đại loại ví dụ hàm A càng ngày càng sử dụng nhiều stack ( tăng kích thước nhớ trên stack ). Dẫn đến một lúc nào đó nó sẽ tràn vào vùng stack của hàm B. Vấn đề đọc mã nhiều lib coroutine thấy nó chỉ lưu trữ- khôi phục rsp vs rbp. Chứ ko hề thực hiện cho tất cả đoạn stack của hàm A.
Đang đọc vấn đề này đang tìm biện pháp xử lý giải quyết. Đang định làm một lib coroutine riêng. Đọc mấy bài trên blog bọn Tây cũng ko nhiều. Tụi nó nói phải làm lại trình dịch ....Nghe sao thấy oải. Ý nói vụ này phải được quy về một tính năng ngôn ngữ. Chứ ko thể dùng lib. Cá nhân dang dùng mấy libco cảm thấy có nhiều chỗ chạy ko hài lòng lắm. Cần tùy chỉnh thêm ....
Thím có cao kiến , xin cho tí ý kiến nào

Tại sao nodejs là single thread

Có 2 loại coroutine, stackful và stackless.
Stackful là mỗi coroutine có một stack riêng, được allocate trên heap. Việc này thì thư viện có thể xử lý được.
Còn stackless là tất cả đều dùng chung một stack giống kiểu như hàm bình thường. Để làm được vậy thì cần có trình dịch hỗ trợ vì chỉ nó mới có thông tin về kích thước của stack frame, địa chỉ các await point. Vậy nên C++20 mới phải ra một tính năng mới để hỗ trợ chứ không dùng thư viện được.

Có bài này khá chi tiết: https://blog.panicsoftware.com/coroutines-introduction/

L1f3 ver 2

Có 2 loại coroutine, stackful và stackless.
Stackful là mỗi coroutine có một stack riêng, được allocate trên heap. Việc này thì thư viện có thể xử lý được.
Còn stackless là tất cả đều dùng chung một stack giống kiểu như hàm bình thường. Để làm được vậy thì cần có trình dịch hỗ trợ vì chỉ nó mới có thông tin về kích thước của stack frame, địa chỉ các await point. Vậy nên C++20 mới phải ra một tính năng mới để hỗ trợ chứ không dùng thư viện được.

Có bài này khá chi tiết: https://blog.panicsoftware.com/coroutines-introduction/

Hay thím ơi, em mới biết vụ này luôn

Tại sao nodejs là single thread

Pianist

Có 2 loại coroutine, stackful và stackless.
Stackful là mỗi coroutine có một stack riêng, được allocate trên heap. Việc này thì thư viện có thể xử lý được.

Hỏi bác thêm chút về cơ chế I/O callback của nodejs. Event loop thì dễ hiểu rồi, sau khi app request đến DB thì bỏ vào stack, đi xử lý tiếp cái khác đợi DB response. Nhưng với single thread thì nodejs làm ntn để keep connection với DB, và biết được DB response để lôi cái callback trong stack ra?

zhukov

Có 2 loại coroutine, stackful và stackless.
Stackful là mỗi coroutine có một stack riêng, được allocate trên heap. Việc này thì thư viện có thể xử lý được.
Còn stackless là tất cả đều dùng chung một stack giống kiểu như hàm bình thường. Để làm được vậy thì cần có trình dịch hỗ trợ vì chỉ nó mới có thông tin về kích thước của stack frame, địa chỉ các await point. Vậy nên C++20 mới phải ra một tính năng mới để hỗ trợ chứ không dùng thư viện được.

Có bài này khá chi tiết: https://blog.panicsoftware.com/coroutines-introduction/

Đúng là vậy , chính mình cũng đang mò đoạn đó. Có lẽ đúng chỉ có compile mới có thông tin đầy đủ về stack frame của coroutine.
- Ngoài ra theo thím có biện pháp nào hay hơn coroutine ko ? Thực tế thèn này vẫn bị mất fee cho context sw. Chơi theo bài event loop có thực sự ổn ko nhở ? Event loop nếu ko multi thread được thì cũng ko ngon lắm. CƠ mà multi thì lại chạm một rổ vấn đề giảm per của thằng Epoll ( đang bàn về linux - os khác ko rõ )

Em ko hiểu ý của thím. Nếu A và B cùng 1 thread thì sẽ ko bao h xảy ra trường hợp đó vì rsp giảm dần sau mỗi lần call hàm. Còn nếu 2 hàn nằm ở 2 thrad khác nhau thì cũng ko bao h stack va vào nhau cả vì 2 thread riêng sẽ tạo ra 2 stack mem khác nhau chứ ko phải là 2 frame khác nhau trên cùng 1 stack

À mình thực sự ko biết có hiểu sai hay hiểu đúng nữa. Đại loại 2 hàm A B cơ mà nó run trong coroutine chứ ko phải 2 hàm được call kiểu bình thường thím ạ. VD Stack của các coroutine được cấp 1KB chẳng hạn. Số này được lấy từ stack của thớt trong tông số 1MB chẳng hạn. Vì quá trình hoạt động của hàm A đôi khi Stack của nó bị push lên nhiều. Vượt quá size 1kB của nó , lấn sang stack của thèn B chẳng hạn. Lúc restore lại hàm B , stack bị thay đổi không còn nguyên vẹn như lúc ban đầu save thằng B.

Dĩ nhiên coroutine nó đã save các thanh ghi theo tiêu c huẩn ABI , tuy nhiên có nhiều dữ liệu trong quá trình chạy của hàm được save tạm trên Stack.
Hi vọng thím hiểu ý mình định nói ...Ko biết có đúng ko hay sai. Thím có cao kiến xin cứ chỉ bảo.

Last edited: Aug 29, 2020

XinClipBiBan

Single hay multi nó tùy thuộc vào runtime-environment chứ chả liên quan gì đến ngôn ngữ, vì vậy nên câu hỏi của chủ thớt trên là sai. Trên trình duyệt thì chỉ cho phép single thread nhưng nodejs phía server có thể chạy multi thread ngon lành.
Còn vụ ông anh trên công ty cũng sai, main thread và worker thread ko dính gì đến nhau cả. Phải nhờ thằng trình duyệt là thằng trung gian cho các thread này giao tiếp với nhau

Tại sao nodejs là single thread

rauma01

đâu cần đợi đâu, truy vấn là IO mà thằng js/node là non-block, còn java thì multi-thread(vẫn có non-blocking IO), còn lại thì coi db nó xử lý concurrency thế nào.

Bạn nói không sai, nhưng nếu xem đây là câu trả lời cho câu hỏi của mình thì cá nhân mình không thể cho "điểm" cao được.

zulu

Bạn nói không sai, nhưng nếu xem đây là câu trả lời cho câu hỏi của mình thì cá nhân mình không thể cho "điểm" cao được.

Cái đề của a lang man vs thiếu dữ kiện vl. Trong java springboot giả sử tôi code ngu đi thì min là 20 phút nhé.

via nextVOZ for iPhone

zulu

đâu cần đợi đâu, truy vấn là IO mà thằng js/node là non-block, còn java thì multi-thread(vẫn có non-blocking IO), còn lại thì coi db nó xử lý concurrency thế nào.

Sao ko cần đợi?
Nói chung đề thiếu dữ kiện lắm. ko đủ để trả lời đc. Vd ở java đi giờ tôi nói min 10 phút hoặc min 20 min đều đúng vì đề thiếu dữ kiện để ràng buộc

via nextVOZ for iPhone

meohen2109

Bạn nói không sai, nhưng nếu xem đây là câu trả lời cho câu hỏi của mình thì cá nhân mình không thể cho "điểm" cao được.

quăng đáp án xem nào, bí bí hiểm hiểm

Tại sao nodejs là single thread

rauma01

quăng đáp án xem nào, bí bí hiểm hiểm

Tại sao nodejs là single thread

Người thứ 2 sẽ phải chờ 10 phút để đăng nhập, cho cả 2 phiên bản js hoặc java.

haSei

cache nó mang nhiều nghĩa lắm bạn ơi :v
edit: ờ ý tôi là nhiều kiểu cache, từ cache opcode, l1 l2 l3 cache rồi thì đủ kiểu. mỗi lần context switch sẽ involve một đống thứ.

hồi trước cũng đọc một vài bài báo về vấn đề này cơ mà giờ quên mất rồi, đợi lúc nào tìm lại :v

Memory cache L1 L2 L3 nó không tự xoá khi switch context đâu bác. Vì nó là cache của core CPU, không liên quan gì thread hết. Mà mình không nghĩ sẽ có cache nào đó sẽ bị xoá khi context switch, mong bác tìm được tài liệu share lại cho mọi người cùng đọc.

haSei

Context switch ở mức process thì có thể sẽ phải flush cache, tùy trường hợp.

Lý do là vì ứng dụng sử dụng địa chỉ bộ nhớ ảo. Nên hoàn toàn có thể phát sinh trường hợp 2 process khác nhau sử dụng chung địa chỉ ảo nhưng thực chất là trỏ đến địa chỉ vật lý khác nhau, hoặc ngược lại là 2 process dùng địa chỉ ảo khác nhau nhưng lại chung địa chỉ vật lý.

Khi đó nếu như cache được tag bằng địa chỉ ảo thì bắt buộc phải flush khi context switch, nếu không sẽ dẫn đến sai lêch. Điều này là khá phổ biến ở cache L1 vì tag địa chỉ ảo nhanh, không cần phải pagewalk để lấy địa chỉ vật lý. L2 và L3 thì thường tag bằng địa chỉ vật lý vì yêu cầu về latency không quá cao như L1, với lại flush L2 với L3 thì tốn chu kỳ CPU (do kích thước nó lớn) và ảnh hưởng đến hiệu năng nhiều ứng dụng khác.

Có một giải pháp đỡ phải flush L1 là gắn thêm pid vào tag để phân biệt, nhưng cái này cũng tùy CPU.

Còn "context switch" theo kiểu async thì chắc không cần flush, vì vẫn chung một thread, chung không gian bộ nhớ ảo.

Nhưng nó không xoá memory cache trong quá trình context switch bác à, nó flush cache trong quá trình thực thi process. Ngoài ra, L1 không được tag bằng virtual memory, L1 là real memory tag, chỉ có index là virtual ( nói nôm na thì memory cache được chia thành nhiều set, mỗi set chứa nhiều line, index là tìm set, tag tìm line). Nói tóm lại, flush cache là do core quyết định, không phải do context switch.

haSei

Context switch ở mức process thì có thể sẽ phải flush cache, tùy trường hợp.

Lý do là vì ứng dụng sử dụng địa chỉ bộ nhớ ảo. Nên hoàn toàn có thể phát sinh trường hợp 2 process khác nhau sử dụng chung địa chỉ ảo nhưng thực chất là trỏ đến địa chỉ vật lý khác nhau, hoặc ngược lại là 2 process dùng địa chỉ ảo khác nhau nhưng lại chung địa chỉ vật lý.

Khi đó nếu như cache được tag bằng địa chỉ ảo thì bắt buộc phải flush khi context switch, nếu không sẽ dẫn đến sai lêch. Điều này là khá phổ biến ở cache L1 vì tag địa chỉ ảo nhanh, không cần phải pagewalk để lấy địa chỉ vật lý. L2 và L3 thì thường tag bằng địa chỉ vật lý vì yêu cầu về latency không quá cao như L1, với lại flush L2 với L3 thì tốn chu kỳ CPU (do kích thước nó lớn) và ảnh hưởng đến hiệu năng nhiều ứng dụng khác.

Có một giải pháp đỡ phải flush L1 là gắn thêm pid vào tag để phân biệt, nhưng cái này cũng tùy CPU.

Còn "context switch" theo kiểu async thì chắc không cần flush, vì vẫn chung một thread, chung không gian bộ nhớ ảo.

Nếu ý bác là async trên js browser, thì thread thực thi task async này không phải do js sinh ra, js không có cơ chế tạo new thread, dù là green hay os. Thread này là của V8 engine, nó là một thread hoàn toàn khác, thông thường là core khác luôn.

haSei

Js là single thread language. Luôn luôn là single thread language. Vì nó không support tạo thread. Có thể dùng js để implement concurrency task, nhưng, không phải là do bản thân js có thể làm concurrency. Js là một ngôn ngữ bậc cao (nói dân dã, là siêu cao), chạy trên nền của một engine khác, thường là viết bằng C. Những engine này, mới thực thi concurrency. JS chỉ là, dùng để tương tác với các engine này thôi. Chỉ vậy thôi. Cơ chế event loop cũng là tính năng của engine. Chỉ có một thread duy nhất thực thi js code. Async task bản chất là API js dùng để call đến engine.

Nipin

các bạn nghĩ phức tạp quá, như tôi thấy thì đơn giản như mấy cái instruction áp dụng cho cả cái array (vector) mỗi lần chạy nhiều khi nó phải load array full cache đúng không? không cần switch process, switch fiber (coroutine) thôi nhiều khi cũng phải load lại rồi. đấy là không nói một số ngôn ngữ memory của mỗi fiber là một stack riêng không chia sẻ, tạo fiber mới (mấy ngôn ngữ dạng này nó tạo fiber liên tục) nhiều khi phải copy lại data (thường copy on write thôi cơ mà vẫn là copy) làm giảm hiệu năng.

hôm nọ tôi hơi bận cho nên giải thích thiếu vụ cache, ý tôi không phải là bảo cache là memory, hay l1 l2 l3, tôi chỉ bảo là từ cache áp dụng dc cho nhiều văn cảnh. cái tôi muốn nói là dù trong một thread thì lúc switch fiber nhiều ngôn ngữ nó vẫn phải load lại data/copy data, cho nên hiệu năng nó tụt.

còn vụ có flush cache hay không thì tôi không nhớ chính xác lắm, cơ mà hình như đã đọc một bài nó nói task scheduler của language (runtime) thường nó tied với os task scheduler để tăng performance... cơ mà hậu quả/ảnh hưởng thế nào thì tôi chả còn nhớ nữa :"> nói chung thông tin không đáng tin các bạn đọc tham khảo thôi.

p/s: mấy tuần nay hơi bệnh không có thời gian double check fact nữa, các bạn đọc thấy sai thì sửa luôn hộ với :">

Last edited: Sep 2, 2020

haSei

Có mấy bác nói có ý đúng về việc lấy ví dụ về vụ js là single threaded.

Mấy bác lấy ví dụ sync code kiểu như: white(true), alert()... là chưa chuẩn đâu nhé, cái này thể hiện code được chạy tuần tự thôi, api alert() là hàm đồng bộ, trong ngôn ngữ Java cũng không thiếu hàm kiểu này: .readLine() (không nhớ lắm, chờ nhận một tín hiệu từ bàn phím).

Trong js bạn không thể lấy được một ví dụ mà trong đó có nhiều hơn một "luồng" cùng truy cập vào một biến. Kiểu như một "luồng" thêm dữ liệu vào mảng, "luồng" khác "pop" dữ liệu từ mảng đó ra.

Như bác này có nói, js không được impl để làm việc ở trên với tư tưởng "multi threaded"

Tiện đây cũng có một câu khác, câu này được hỏi để phân cấp "trên" fresher hay không? Thật khó để ngay lập tức phân loại được một ứng viên, nhưng mình nghĩ với câu này là khá ok:

"JS là single threaded. Có 2 api để đăng nhập [1 bằng js chạy trên nodejs (express), 1 bằng Java với spring bot], người dùng sẽ gửi lên user/pass, api service truy vấn tới database để trả ra kết quả đăng nhập thành công hay không?. Database là mysql, truy vấn login luôn mất 10 phút

Tại sao nodejs là single thread
. Nếu có 2 người dùng đăng nhập lần lượt đồng thời
Tại sao nodejs là single thread
(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.

Bác Zuru nói đúng á bác. Nếu người ta hỏi vặn thì đề này thiếu dữ kiện thật sự. Bác đang mặc định cách implement chuẩn của NodeJS và spring boot, trong happy case. Đúng là mấy câu này chỉ nên hỏi cho trên fresher một chút.

haSei

các bạn nghĩ phức tạp quá, như tôi thấy thì đơn giản như mấy cái phép tính liên quan tới array mỗi lần chạy nhiều khi nó phải load array full cache đúng không? không cần switch process, switch fiber (coroutine) thôi nhiều khi cũng phải load lại rồi. đấy là không nói một số ngôn ngữ memory của mỗi fiber là một stack riêng không chia sẻ, tạo fiber mới (mấy ngôn ngữ dạng này nó tạo fiber liên tục) nhiều khi phải copy lại data (thường copy on write thôi cơ mà vẫn là copy) làm giảm hiệu năng.

hôm nọ tôi hơi bận cho nên giải thích thiếu vụ cache, ý tôi không phải là bảo cache là memory, hay l1 l2 l3, tôi chỉ bảo là từ cache áp dụng dc cho nhiều văn cảnh. cái tôi muốn nói là dù trong một thread thì lúc switch fiber nhiều ngôn ngữ nó vẫn phải load lại data/copy data, cho nên hiệu năng nó tụt.

còn vụ có flush cache hay không thì tôi không nhớ chính xác lắm, cơ mà hình như đã đọc một bài nó nói task scheduler của language (runtime) thường nó tied với os task scheduler để tăng performance... cơ mà hậu quả/ảnh hưởng thế nào thì tôi chả còn nhớ nữa :"> nói chung thông tin không đáng tin các bạn đọc tham khảo thôi.

p/s: mấy tuần nay hơi bệnh không có thời gian double check fact nữa, các bạn đọc thấy sai thì sửa luôn hộ với :">

Đúng. Access array nhiều sẽ đè lại memory cache. Nhưng, nó vẫn là lúc thực thi code, không phải lúc switch context. Ngôn ngữ nào switch coroutine trong một thread phải load lại data vậy bác, cho em tư liệu được không. Còn context switch giữa os thread là không có xoá cache hay data liên quan gì đến thread hết, thread nào giữ nguyên thread đó. Green thread của Java cũng vậy.

Nipin

Đúng. Access array nhiều sẽ đè lại memory cache. Nhưng, nó vẫn là lúc thực thi code, không phải lúc switch context. Ngôn ngữ nào switch coroutine trong một thread phải load lại data vậy bác, cho em tư liệu được không. Còn context switch giữa os thread là không có xoá cache hay data liên quan gì đến thread hết, thread nào giữ nguyên thread đó. Green thread của Java cũng vậy.

không phải là switch coroutine, bạn có thể hiểu thế này: fiber/coroutine nó không phải là long time thread, mà là chạy trong khoảng thời gian cực ngắn, xong tác vụ phần lớn là nó tự huỷ, trong một cái process đang chạy fiber được tạo mới rồi chết liên tục (ví dụ mỗi connection http từ client là một fiber, giải quyết xong fiber chết luôn), mỗi lần tạo mới này nó lại allocate stack, copy data (on write) các kiểu. tuy mấy cái này không tốn bao nhiêu tài nguyên (so với tạo thread), nhưng tóm lại là có overhead.

ví dụ cho vụ tạo fiber siêu ngắn hạn này thì có thằng BEAM ấy.

haSei

không phải là switch coroutine, bạn có thể hiểu thế này: fiber/coroutine nó không phải là long time thread, mà là chạy trong khoảng thời gian cực ngắn, xong tác vụ phần lớn là nó tự huỷ, trong một cái process đang chạy fiber được tạo mới rồi chết liên tục (ví dụ mỗi connection http từ client là một fiber, giải quyết xong fiber chết luôn), mỗi lần tạo mới này nó lại allocate stack, copy data (on write) các kiểu. tuy mấy cái này không tốn bao nhiêu tài nguyên (so với tạo thread), nhưng tóm lại là có overhead.

ví dụ cho vụ tạo fiber siêu ngắn hạn này thì có thằng BEAM ấy.

Vậy Allocate stack hay copy data là những tác vụ của os hoặc virtual machine hoặc của thread thực thi fiber/coroutine, không ảnh hưởng gì đến cache hay data của os thread, green thread hay fiber/coroutine. Cũng không ảnh hưởng đến memory cache của core. Em chỉ muốn làm rõ điểm này.

meohen2109

Người thứ 2 sẽ phải chờ 10 phút để đăng nhập, cho cả 2 phiên bản js hoặc java.

Good.

Sent from Sony F3116 using vozFApp

bribnt

Nhưng nó không xoá memory cache trong quá trình context switch bác à, nó flush cache trong quá trình thực thi process. Ngoài ra, L1 không được tag bằng virtual memory, L1 là real memory tag, chỉ có index là virtual ( nói nôm na thì memory cache được chia thành nhiều set, mỗi set chứa nhiều line, index là tìm set, tag tìm line). Nói tóm lại, flush cache là do core quyết định, không phải do context switch.

Vụ này tùy nhé bác, như mình đã nói.
Mấy dòng hiện tại của intel, amd, arm thì tag bằng physical. Nhưng một số dòng cũ của arm như armv5 thì tag bằng virtual address, nên os phải flush cache khi context switch.

Sent from Xiaomi Redmi 5A using vozFApp

haSei

Vụ này tùy nhé bác, như mình đã nói.
Mấy dòng hiện tại của intel, amd, arm thì tag bằng physical. Nhưng một số dòng cũ của arm như armv5 thì tag bằng virtual address, nên os phải flush cache khi context switch.

Sent from Xiaomi Redmi 5A using vozFApp

Thank bác, đúng là như bác nói.

anhsuperstar

Single thread nhưng lại là multiple process

anhsuperstar

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 được

Thím này nói chuẩn này

Tại sao nodejs là single thread
Tại sao nodejs là single thread

4nh7i3m

Người thứ 2 sẽ phải chờ 10 phút để đăng nhập, cho cả 2 phiên bản js hoặc java.

Ơ tui tưởng là 30s chứ. Các HTTP Connection nào cũng có timeout mà. Chờ hoài không có trả lời cùng lắm 1p,2p lằ tắt browser rồi. Ai rãnh hơi ngồi chờ 10p nhỉ. Joke.

Tại sao nodejs là single thread
.

Công nhận trong này có mấy lão tìm hiểu hardcore thật. Tui code chạy không bug là mừng lắm rồi luôn á.

Tại sao nodejs là single thread
.

zulu

Người thứ 2 sẽ phải chờ 10 phút để đăng nhập, cho cả 2 phiên bản js hoặc java.

Câu hỏi vs câu trả lời lỗ hổng lỗ chỗ thím ợ

meohen2109

Câu hỏi vs câu trả lời lỗ hổng lỗ chỗ thím ợ

đồng chí đấy trả lời thấy kì quá, ko giải thích, ko chứng minh ...

Tại sao nodejs là single thread

rauma01

Câu hỏi vs câu trả lời lỗ hổng lỗ chỗ thím ợ

Câu hỏi của mình là câu hỏi phỏng vấn trực tiếp, chỉ để xem bạn có thực sự sẵn sàng cho cấp cao hơn fresher hay không. Với câu hỏi này mình chỉ quan tâm tới "thời gian", nên mình mong muốn câu trả lời nhanh, dứt khoát, rõ ràng và tất nhiên phải trả lời được "bao lâu".

Lỗ hổng trong câu hỏi thì mình cũng đã thấy, rất nhiều ứng viên hỏi tương tự như các bạn trong thớt này, tốc độ mạng giữa client server, giữa server với db, tốc độ vi xử lý của máy chủ, thời gian thực thi tính bằng milliseconds... (Nhưng code ngu để server chậm đi thì mới gặp ở thớt này, có thể vì đây không phải là pv trực tiếp).

Mình không cố tình chơi chữ, hay ẩn ý trong câu hỏi, mình chỉ muốn đảm bảo một fresher thì phải hiểu "js single threaded", đơn giản thế thôi. Đơn vị thời gian trong câu hỏi của mình là "phút", không đến mức phải tính tới mức độ CPU như các thánh trong này (những vẫn đề các thành nói trong này mình cũng lơ mơ). Tất nhiên, có những người họ nắm được cơ bản, họ biết cách "khóa" điều điện trong câu trả lời, kiểu như "Nếu không có gì đặc biệt (trong "điều kiện phòng", điều kiện lý tưởng....), thời gian phải đợi là....", mình đánh giá cao những người đó.

Với những người có câu hỏi chỉ ra lỗ hổng trong câu hỏi và họ đăng ứng tuyển vị trí junior, mình vẫn cảm ơn họ và bỏ qua câu hỏi đó. Sau đó, mình phải đưa cho họ làm một bảng câu hỏi trắc nghiệm nhàm chán dành cho fresher. Những câu hỏi trong đó khá máy móc, hỏi về những điểm "dị" của ngôn ngữ, cú pháp...và nó thực sự phù hợp nếu bạn là fresher.

prescolt

Doc cái thread này, có một bộ phận không nhỏ lập trình viên xác định ngôn ngữ là đa luồn hay đơn luồn dựa vào các hàm trong ngôn ngữ ?. Cuối cùng là nó vô tình đúng, nhưng bản chất thì sai hoàn toàn

haSei

Doc cái thread này, có một bộ phận không nhỏ lập trình viên xác định ngôn ngữ là đa luồn hay đơn luồn dựa vào các hàm trong ngôn ngữ ?. Cuối cùng là nó vô tình đúng, nhưng bản chất thì sai hoàn toàn

Lập trình là một thế giới rất rộng, thú vị và màu sắc. Người hiểu sai người hiểu đúng người không hiểu là chuyện rất bình thường. Bản chất của công nghệ vốn là học hỏi và tìm hiểu bác nhỉ. Vậy tại sao bác không chia sẻ, tranh luận, giúp đỡ mọi người mà phải buông một câu nói để tìm kiếm cảm giác thượng đẳng như vậy nhỉ?

prescolt

Lập trình là một thế giới rất rộng, thú vị và màu sắc. Người hiểu sai người hiểu đúng người không hiểu là chuyện rất bình thường. Bản chất của công nghệ vốn là học hỏi và tìm hiểu bác nhỉ. Vậy tại sao bác không chia sẻ, tranh luận, giúp đỡ mọi người mà phải buông một câu nói để tìm kiếm cảm giác thượng đẳng như vậy nhỉ?

Gần cuối thread này đã có người nói rồi, hay bạn này éo thèm đọc , còn bạn nói tôi thượng đẳng thi tôi nhận thôi, chứ tôi ko nói nhé.

soihoang

Doc cái thread này, có một bộ phận không nhỏ lập trình viên xác định ngôn ngữ là đa luồn hay đơn luồn dựa vào các hàm trong ngôn ngữ ?. Cuối cùng là nó vô tình đúng, nhưng bản chất thì sai hoàn toàn

chưa có ngôn ngữ nào đa luồn hay đơn luồn cả bác ạ

Tại sao nodejs là single thread

meohen2109

Câu hỏi của mình là câu hỏi phỏng vấn trực tiếp, chỉ để xem bạn có thực sự sẵn sàng cho cấp cao hơn fresher hay không. Với câu hỏi này mình chỉ quan tâm tới "thời gian", nên mình mong muốn câu trả lời nhanh, dứt khoát, rõ ràng và tất nhiên phải trả lời được "bao lâu".

Sốc nha, bạn hỏi một câu đầy lỗ hổng, mà chỉ cần biết đáp án ra nhanh hay chậm, là nhận xét được trình độ "ban đầu" của người ta

Tại sao nodejs là single thread

Last edited: Sep 4, 2020

ldarj3

các bác cho e hỏi với, tại sao khi gọi hàm setTimeout mặc dù để 0 millisecond nhưng nó vẫn ra kết quả sau console.log mặc dù nó được gọi trước vậy ạ

rauma01

Sốc nha, bạn hỏi một câu đầy lỗ hổng, mà chỉ cần biết đáp án ra nhanh hay chậm, là nhận xét được trình độ "ban đầu" của người ta

Tại sao nodejs là single thread

Một kiểu phủ đầu cân não khi face to face chăng?

Vậy mình nghĩ câu hỏi kiểu này, và phong cách trả lời này, chỉ hợp với bên F33 thôi.

Cũng có thể. Bạn giữ những “lỗ hổng” cho bạn, mình giữ công việc cho cty.

via theNEXTvoz for iPhone

teeeeeeeee

các bác cho e hỏi với, tại sao khi gọi hàm setTimeout mặc dù để 0 millisecond nhưng nó vẫn ra kết quả sau console.log mặc dù nó được gọi trước vậy ạ

Bạn xem event loop là sẽ hiểu nhé

via theNEXTvoz for iPhone

haSei

Gần cuối thread này đã có người nói rồi, hay bạn này éo thèm đọc , còn bạn nói tôi thượng đẳng thi tôi nhận thôi, chứ tôi ko nói nhé.

Bác không hiểu ý mìnht

Gần cuối thread này đã có người nói rồi, hay bạn này éo thèm đọc , còn bạn nói tôi thượng đẳng thi tôi nhận thôi, chứ tôi ko nói nhé.

Vì mình nghĩ thread này là tranh luận cơ. Mọi người cùng nhau tranh luận và đóng góp ý kiến. Thế nên trong đoạn rep của bác, không có dữ liệu gì có ích cho một câu tranh luận cả. Vì sao hiểu theo các hàm của ngôn ngữ là sai? Sai ở bản chất vậy bản chất thế nào là đúng? Câu cmt của bác đơn thuần là phán xét một bộ phận "lập trình viên Việt Nam" chứ không cung cấp thông tin được gì cụ thể cả. Có rất nhiều comment giải thích về Js, vậy ai đúng, cmt gần cuối là cmt nào?
Tất nhiên là mình dở hơi, nhưng đây không phải F33 hay F17, mình coi đây là nơi trao đổi và học tập kinh nghiệm, kỹ năng. Nên thật sự chướng mắt với những cmt không có hàm lượng ý nghĩa mà chỉ để thể hiện cái tôi cá nhân.

greans

các bác cho e hỏi với, tại sao khi gọi hàm setTimeout mặc dù để 0 millisecond nhưng nó vẫn ra kết quả sau console.log mặc dù nó được gọi trước vậy ạ

Nôm na là vì setTimeout để schedule function sau current main thread.

nntgwww

Cha prescot làm network là chính mà nên thượng đẳng hơn ltv la đúng rồi. Đi đâu thì chả thấy chê dev thế này thế nọ làm tốn tài nguyên server của chả

Tại sao nodejs là single thread
.

Nói chớ hồi trươc bên f17 chả có 2pic phân biệt đối xử dân helpdesk network chả vào sửng cồ gáy rồi quay lại chửi cả dev

Tại sao nodejs là single thread
. Trong khi nhiều dev cũng ko đồng ý phân biệt khinh bỉ help desk, network.

Last edited: Sep 3, 2020

soihoang

Cha prescot làm network là chính mà nên thượng đẳng hơn ltv la đúng rồi. Đi đâu thì chả thấy chê dev thế này thế nọ làm tốn tài nguyên server của chả

Tại sao nodejs là single thread
.

Nói chớ hồi trươc bên f17 chả có 2pic phân biệt đối xử dân helpdesk network chả vào sửng cồ gáy rồi quay lại chửi cả dev

Tại sao nodejs là single thread

đi làm đéo sợ khó sợ khổ, mà sợ kiểu sống c*ó này

zulu

Cũng có thể. Bạn giữ những “lỗ hổng” cho bạn, mình giữ công việc cho cty.

via theNEXTvoz for iPhone

Câu hỏi của mình là câu hỏi phỏng vấn trực tiếp, chỉ để xem bạn có thực sự sẵn sàng cho cấp cao hơn fresher hay không. Với câu hỏi này mình chỉ quan tâm tới "thời gian", nên mình mong muốn câu trả lời nhanh, dứt khoát, rõ ràng và tất nhiên phải trả lời được "bao lâu".

Cái này và những điêu thím nói mình hiểu.
Nhưng câu hỏi và cách phán xét quá cảm tính chủ quan. Trong đây là thảo luận thì tôi mới hỏi lại thím edge case như thế.

Chứ pv giờ có ứng viên trả lời NHANH và DỨT KHOÁT: ít nhất là khoảng 20 phút.
-> thì thím làm sao? Đánh rớt ko cần hỏi ngta vì sao luôn hả?

Last edited: Sep 3, 2020

prescolt

Cha prescot làm network là chính mà nên thượng đẳng hơn ltv la đúng rồi. Đi đâu thì chả thấy chê dev thế này thế nọ làm tốn tài nguyên server của chả

Tại sao nodejs là single thread
.

Nói chớ hồi trươc bên f17 chả có 2pic phân biệt đối xử dân helpdesk network chả vào sửng cồ gáy rồi quay lại chửi cả dev

Tại sao nodejs là single thread
. Trong khi nhiều dev cũng ko đồng ý phân biệt khinh bỉ help desk, network.

Networking
System
Code (backend)
Nhiêu này đủ chưa. Nên thằng dev nào vẽ hưu vẽ vượn là coi chừng. Tui tự tin trình độ của mình. Làm IT ở VN đi xe oto làm hằng ngày, có nhà, có công ty riêng thì ko thể nào ngu được đâu bạn. Tôi chê nhửng cái đáng phải chê. Còn dân học lập trình người ta đã chỉ ra phán xét ngon ngữ chạy thế nào nằm ở kiến trúc của nó chứ ko phải câu lệnh, hàm gì, làm lập trình tự biết đó mà tìm hiểu thêm, ai rãnh hơi chi chỉ chi tiết lí do blabla, người ta chỉ cần gợi ý là đủ.
À tôi chửi mấy thằng dev vì mấy thằng dev nói thằng làm system chỉ biết dùng cái có sẵn, người ta làm sẵn ra xài, có gì xài đó, bọn dev cũng bắt đầu với hello word mà cũng có dev ngu ,dev cứng tay thôi thì system cũng vậy, xóc xĩa làm éo gì

Last edited: Sep 3, 2020

HutCanPheLam

Networking
System
Code (backend)
Nhiêu này đủ chưa. Nên thằng dev nào vẽ hưu vẽ vượn là coi chừng. Tui tự tin trình độ của mình. Làm IT ở VN đi xe oto làm hằng ngày, có nhà, có công ty riêng thì ko thể nào ngu được đâu bạn. Tôi chê nhửng cái đáng phải chê. Còn dân học lập trình người ta đã chỉ ra phán xét ngon ngữ chạy thế nào nằm ở kiến trúc của nó chứ ko phải câu lệnh, hàm gì, làm lập trình tự biết đó mà tìm hiểu thêm, ai rãnh hơi chi chỉ chi tiết lí do blabla, người ta chỉ cần gợi ý là đủ.
À tôi chửi mấy thằng dev vì mấy thằng dev nói thằng làm system chỉ biết dùng cái có sẵn, người ta làm sẵn ra xài, có gì xài đó, bọn dev cũng bắt đầu với hello word mà cũng có dev ngu ,dev cứng tay thôi thì system cũng vậy, xóc xĩa làm éo gì

Sư phụ ơi em đang đi theo con đường của sư phụ này. Sư phụ chỉ đường e với

nntgwww

Networking
System
Code (backend)
Nhiêu này đủ chưa. Nên thằng dev nào vẽ hưu vẽ vượn là coi chừng. Tui tự tin trình độ của mình. Làm IT ở VN đi xe oto làm hằng ngày, có nhà, có công ty riêng thì ko thể nào ngu được đâu bạn. Tôi chê nhửng cái đáng phải chê. Còn dân học lập trình người ta đã chỉ ra phán xét ngon ngữ chạy thế nào nằm ở kiến trúc của nó chứ ko phải câu lệnh, hàm gì, làm lập trình tự biết đó mà tìm hiểu thêm, ai rãnh hơi chi chỉ chi tiết lí do blabla, người ta chỉ cần gợi ý là đủ.
À tôi chửi mấy thằng dev vì mấy thằng dev nói thằng làm system chỉ biết dùng cái có sẵn, người ta làm sẵn ra xài, có gì xài đó, bọn dev cũng bắt đầu với hello word mà cũng có dev ngu ,dev cứng tay thôi thì system cũng vậy, xóc xĩa làm éo gì

Trước nhất cái vấn đề ông kia nói ko có sai. Vô 2pic này ko có gì chi thốt ra lập trình viên thế này thế nọ ko xóc xỉa chứ còn gì. Diễn đàn mục đích thảo luận ai biết thì trả lời, ai ko biết thì hỏi. Có gì đâu. AI thích trả lời chi tiết thì trả lời, câu hỏi nào ngu thì tự khắc ko ai trả lời.

Anh giải thích thì kiểu có người này người kia chứ mấy câu anh thốt ra kiểu dân lập trình viên thì ai mà tin cho nổi.

Tại sao nodejs là single thread
. Gì chứ với lịch sử qua mấy 2pic flame system network voz old tôi có lạ anh ếu đâu. Dev deploy ngu làm hư network tao setup, dev cũng ngu mà đòi chủi dân network. Vơ đũa cả nắm thì cũng có kém mấy thằng gây flame. Nên vào bô bô dân ltv thế này thế nọ cũng thói quen cũ cả thôi.

Ko giúp gì kiến thức chỉ vào nói ra vẻ thượng đẳng, nói đúng quá còn giẫy nãy lên làm gì. Còn nói kiều người ta chỉ cần gợi ý là đủ, vậy anh nghĩ thế nào là đủ?. Ngay cả 2pic bản thân anh cũng ko giúp dc cái gợi ý nào cả?. Nếu chỉ cần gợi ý thì đóng cửa cái box. ae ltv gì gì đó lại ngồi cày stack overflow với reddit cho rồi?. Anh cứ xem cái box này trình độ mẫu giáo là dc rồi. Tư tin trình độ của mình thì ko cần nhất thiết thể hiện với mẫu giáo là đc, KIếm chỗ nào chơi cho phù hơp trinh độ.

Đã ko nói dc gì hay còn ráng vô tỏ vẻ thượng đẳng. Cho dù anh có ngụy biện tao ko có ý đó thì cách thái độ khiến người ta suy nghĩ khác thế éo nào dc.

Last edited: Sep 4, 2020

prescolt

Bác không hiểu ý mìnht

Vì mình nghĩ thread này là tranh luận cơ. Mọi người cùng nhau tranh luận và đóng góp ý kiến. Thế nên trong đoạn rep của bác, không có dữ liệu gì có ích cho một câu tranh luận cả. Vì sao hiểu theo các hàm của ngôn ngữ là sai? Sai ở bản chất vậy bản chất thế nào là đúng? Câu cmt của bác đơn thuần là phán xét một bộ phận "lập trình viên Việt Nam" chứ không cung cấp thông tin được gì cụ thể cả. Có rất nhiều comment giải thích về Js, vậy ai đúng, cmt gần cuối là cmt nào?
Tất nhiên là mình dở hơi, nhưng đây không phải F33 hay F17, mình coi đây là nơi trao đổi và học tập kinh nghiệm, kỹ năng. Nên thật sự chướng mắt với những cmt không có hàm lượng ý nghĩa mà chỉ để thể hiện cái tôi cá nhân.

Bạn nhạy cảm như mấy bé dậy thì vậy, Chỉ ra rồi thì tự tìm hiểu tại sao là sai.

Sư phụ ơi em đang đi theo con đường của sư phụ này. Sư phụ chỉ đường e với

Con đường này những ngay đầu là chui gầm bàn, đã chui gầm bàn chưa

haSei

Networking
System
Code (backend)
Nhiêu này đủ chưa. Nên thằng dev nào vẽ hưu vẽ vượn là coi chừng. Tui tự tin trình độ của mình. Làm IT ở VN đi xe oto làm hằng ngày, có nhà, có công ty riêng thì ko thể nào ngu được đâu bạn. Tôi chê nhửng cái đáng phải chê. Còn dân học lập trình người ta đã chỉ ra phán xét ngon ngữ chạy thế nào nằm ở kiến trúc của nó chứ ko phải câu lệnh, hàm gì, làm lập trình tự biết đó mà tìm hiểu thêm, ai rãnh hơi chi chỉ chi tiết lí do blabla, người ta chỉ cần gợi ý là đủ.
À tôi chửi mấy thằng dev vì mấy thằng dev nói thằng làm system chỉ biết dùng cái có sẵn, người ta làm sẵn ra xài, có gì xài đó, bọn dev cũng bắt đầu với hello word mà cũng có dev ngu ,dev cứng tay thôi thì system cũng vậy, xóc xĩa làm éo gì

Nên mình mới nói bác là người thích tỏ ra thượng đẳng.

Networking
System
Code (backend)
Nhiêu này đủ chưa. Nên thằng dev nào vẽ hưu vẽ vượn là coi chừng. Tui tự tin trình độ của mình. Làm IT ở VN đi xe oto làm hằng ngày, có nhà, có công ty riêng thì ko thể nào ngu được đâu bạn. Tôi chê nhửng cái đáng phải chê. Còn dân học lập trình người ta đã chỉ ra phán xét ngon ngữ chạy thế nào nằm ở kiến trúc của nó chứ ko phải câu lệnh, hàm gì, làm lập trình tự biết đó mà tìm hiểu thêm, ai rãnh hơi chi chỉ chi tiết lí do blabla, người ta chỉ cần gợi ý là đủ.
À tôi chửi mấy thằng dev vì mấy thằng dev nói thằng làm system chỉ biết dùng cái có sẵn, người ta làm sẵn ra xài, có gì xài đó, bọn dev cũng bắt đầu với hello word mà cũng có dev ngu ,dev cứng tay thôi thì system cũng vậy, xóc xĩa làm éo gì

Giữa một trăm câu comment học hỏi, trao đổi kinh nghiệm, đột nhiên nảy ra một câu phán xét vô ích, bác có thấy bác dở hơi không? Thứ nhất, gợi ý của bác không có lập luận, vậy nó chỉ là câu nói sáo rỗng. Bác là Brendan Eich? Hay mọi người ở đây là nhân viên của bác? Thứ hai, ngành này rất rộng lớn, mọi người đều có thể học hỏi lẫn nhau. Một kiến thức bác nghĩ là đúng, đến một ngày được chứng minh không hẳn đúng hoàn toàn, là chuyện bình thường. Đó là vẻ đẹp của công nghệ. Vậy bác xóc xỉa để được cái éo gì? Thứ ba, câu cmt của bác có tác dụng gì? Giúp đỡ người khác? Không. Tạo môi trường tranh luận? Không. Học hỏi kiến thức? Không. Vậy bác cmt làm éo gì, ở trong cái thread này?
Nhắc lại, đây không phải là F33 hay F17.
Theo kinh nghiệm của mình, thường những người tự ti mới hay chê bai người khác.
Mình sẽ stop những câu cmt làm loãng thớt của mình ở đây.

prescolt

Nên mình mới nói bác là người thích tỏ ra thượng đẳng.

Giữa một trăm câu comment học hỏi, trao đổi kinh nghiệm, đột nhiên nảy ra một câu phán xét vô ích, bác có thấy bác dở hơi không? Thứ nhất, gợi ý của bác không có lập luận, vậy nó chỉ là câu nói sáo rỗng. Bác là Brendan Eich? Hay mọi người ở đây là nhân viên của bác? Thứ hai, ngành này rất rộng lớn, mọi người đều có thể học hỏi lẫn nhau. Một kiến thức bác nghĩ là đúng, đến một ngày được chứng minh không hẳn đúng hoàn toàn, là chuyện bình thường. Đó là vẻ đẹp của công nghệ. Vậy bác xóc xỉa để được cái éo gì? Thứ ba, câu cmt của bác có tác dụng gì? Giúp đỡ người khác? Không. Tạo môi trường tranh luận? Không. Học hỏi kiến thức? Không. Vậy bác cmt làm éo gì, ở trong cái thread này?
Nhắc lại, đây không phải là F33 hay F17.
Theo kinh nghiệm của mình, thường những người tự ti mới hay chê bai người khác.
Mình sẽ stop những câu cmt làm loãng thớt của mình ở đây.

Mình chẳng có gì để mà tư ti cả, kinh nghiệm của bạn không phải là kinh nghiệm của người khác. Câu post trên nếu quan tâm thì tự đi tìm hiểu tại sao như vậy, trong sự nghiệp nhiều lúc người ta chỉ cần một gợi ý nhỏ thôi là nhảy vọt. Phần còn lại là bản thân nghĩ sao về nó, có tìm hiểu hay không hay lại nói thế này thế kia, vô thưởng vô phạt blabal, không có đóng góp vâng vâng...tại bạn làm biếng thôi.
Trong thread này có người đã viết, ngôn ngữ ko có mutex là ko phải đa luồn tôi bổ sung thêm ko có shared memory. Còn đi vô hàm gọi mà phán xét ko có đa luồng, thì theo kinh nghiệm của tôi đây là kiểu lập trình viên suốt ngày đi lên github search cái này cái kia về xài kiểu mấy ông thợ gõ thôi

nguyenna

Vừa đọc 1 bài JS, theo mình hiểu ngắn gọn (liên quan tới topic

Tại sao nodejs là single thread
)
JS chạy ở phía trình duyệt (V8) là single threaded, có điều thứ tự code thực hiện có thể bị thay đổi.
Ở phía server NodeJS thiết kế event loop khác chút so với browser nhưng JS code chạy trong này vẫn là single threaded. Có điều Node thủ sẵn vài threads để xử lý các event tốn thời gian; nếu dùng đến thì main thread chỉ cần nhận kết quả thay vì tự thực hiện.

prescolt

Vừa đọc 1 bài JS, theo mình hiểu ngắn gọn (liên quan tới topic

Tại sao nodejs là single thread
)
JS chạy ở phía trình duyệt (V8) là single threaded, có điều thứ tự code thực hiện có thể bị thay đổi.
Ở phía server NodeJS thiết kế event loop khác chút so với browser nhưng JS code chạy trong này vẫn là single threaded. Có điều Node thủ sẵn vài threads để xử lý các event tốn thời gian; nếu dùng đến thì main thread chỉ cần nhận kết quả thay vì tự thực hiện.

Có thể dùng một ngôn ngữ C hay Java để viết mô phỏng lại event loop của node js muc đích concurrency mà chạy được đa luồng. Mutithread, mỗi thread muti concurrency, non blocking. Hàng mì ăn liền thì nó tới đó thôi

nntgwww

Thấy nên lập thêm box hội người già exp cao. Để các anh già bàn chuyện hack hệ thống này, triển khai hệ thống kia 100tr user, chứ cái này box chung trình độ có bằng mấy anh ếu đâu

Tại sao nodejs là single thread
. Xài mấy lang mì ăn liên mà lập 2pic hỏi han kieu newbie là sẽ bị hội dev già ra dè bỉu, sao ko dung C#, Java, thợ code ko biết google liền.

Ai mà câu hỏi newbie thật sự tôi khuyến khích lên group FB hỏi. Trên đó ai cũng sống bằng nick thật nên nó khác nhiều. Có cái FB đúng là ko phải chuyên lắm, nhưng tôi thấy newbie ít ra còn ko bị mấy anh dev già gang bang

Tại sao nodejs là single thread
. Câu hỏi còn có người tra lời. Hỏi ngu lắm mới ko có ai trả lời. Mà thái độ thì nhiệt tình ít khinh khỉnh như trên đây. Box voz chỉ phù họp dev già khó tính thôi.

chứ nói thiệt lên reddit xem cả ngày có cả chục thớt hỏi còn ngu hơn thế này. Nhưng vấn đề ra vẻ thượng đẳng, khinh miệt chửi bới, cmt ko có tính xây dựng, report, down vote là bay màu hết.

Last edited: Sep 4, 2020

lucius1605

các bác cho e hỏi với, tại sao khi gọi hàm setTimeout mặc dù để 0 millisecond nhưng nó vẫn ra kết quả sau console.log mặc dù nó được gọi trước vậy ạ

hình dung cơ chế của setTimeOut chỉ là add một cái callback vào một stack (First in First out)
setTimeout là 0s nhưng cái callback đó vẫn phải đợi các callback và code khác trong stack chạy trước

prescolt

Bạn trên nhạy cảm quá, thấy có ai chửi bới gì trong này đâu. Mỳ ăn liền thì nói mì ăn liền, có ai nói là ko được xài mì ăn liền đâu.
Right tool for right job. Có gì phải lăn tăn nhỉ.

haSei

Mình chẳng có gì để mà tư ti cả, kinh nghiệm của bạn không phải là kinh nghiệm của người khác. Câu post trên nếu quan tâm thì tự đi tìm hiểu tại sao như vậy, trong sự nghiệp nhiều lúc người ta chỉ cần một gợi ý nhỏ thôi là nhảy vọt. Phần còn lại là bản thân nghĩ sao về nó, có tìm hiểu hay không hay lại nói thế này thế kia, vô thưởng vô phạt blabal, không có đóng góp vâng vâng...tại bạn làm biếng thôi.
Trong thread này có người đã viết, ngôn ngữ ko có mutex là ko phải đa luồn tôi bổ sung thêm ko có shared memory. Còn đi vô hàm gọi mà phán xét ko có đa luồng, thì theo kinh nghiệm của tôi đây là kiểu lập trình viên suốt ngày đi lên github search cái này cái kia về xài kiểu mấy ông thợ gõ thôi

Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.

haSei

Có thể dùng một ngôn ngữ C hay Java để viết mô phỏng lại event loop của node js muc đích concurrency mà chạy được đa luồng. Mutithread, mỗi thread muti concurrency, non blocking. Hàng mì ăn liền thì nó tới đó thôi

Mỗi Thread multi concurrency nghĩa là gì nhỉ. Mình đọc không được thuận miệng cho lắm. Bác có chắc về thuật ngữ này không?

nntgwww

Bạn trên nhạy cảm quá, thấy có ai chửi bới gì trong này đâu. Mỳ ăn liền thì nói mì ăn liền, có ai nói là ko được xài mì ăn liền đâu.
Right tool for right job. Có gì phải lăn tăn nhỉ.

A nói vụ mì ăn liên tôi mới nhớ nhân tiện nói thêm 1 vài vấn đề trong box này thôi. Mây anh dev già khó tính xem language cũng chia thượng đẳng lắm. Bên nodejs thread a có cmt gì thì bữa trước tôi vẫn thấy thôi.
Còn language thì chỉ có 2 loai thôi. Loại có người xài và ko ai xài.

prescolt

Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.

Bạn viết mutithread mà ko xài shared memory thì tôi đặt vấn đề đơn giản như một cái ứng dụng firewall chạy đa luồn có khai bao một pool whitelist ip, ko share cho nhau vậy 32 cái thread khởi tạo 32 cái danh sách IP pool này có phải là sự tiêu tốn tài nguyên không ? rồi khi update 1 cái ip vào pool thì 32 cái thread thi nhau update, ok fine nếu chạy nhẹ nhàng ko vấn đề gì, nhưng thử nghĩ xem với một ứng dụng concurrent tầm 1tr req 1 lúc thì. Ko cần shared memory chạy muti thread thì khác gì muti process ? cứ fork ra rồi chạy, viết thread làm gì cho khổ dâm.
- Block với non blocking là cách hệ thống các thao tác trong code, bản thân ngôn ngữ làm éo gì có khái niệm ngôn ngữ blocking với nonblocking. Đây chỉ là thuật ngữ mấy thằng cuổng nodejs đưa ra, nào là nodejs no blocking balabla, bản chất vấn đề ko phải ở ngôn ngữ mà là nó thiết kế dể chay non blocking đơn giản để deploy, ko phức tạp như C hay java. Và bây giờ người ta nâng tầm thương hiệu node js là ngôn ngữ non blocking

Tại sao nodejs là single thread
, rồi xếp mấy thằng C vói java vào blocking, trong khi bản chất vấn đề là code ngu C với java nên ko làm duoc non blocking nên có thằng tạo ra cái nodejs cho các dev nữa mùa or nhu cầu đơn giản nhanh gọn vô xài thôi. Tôi ko chê ai xài nodeJS nhé, ko lại bảo tôi kinh bỉ

Last edited: Sep 4, 2020

prescolt

Mỗi Thread multi concurrency nghĩa là gì nhỉ. Mình đọc không được thuận miệng cho lắm. Bác có chắc về thuật ngữ này không?

Muti thread, bên trong event loop chứ gì mà thắc mắc, ngày xưa không có nodeJS người ra ko viet duoc ứng dụng mutithread ko chay duoc concurreny mạnh à

Nipin

vozer có một câu nói tôi thấy khá chuẩn "mấy thằng ra rả đạo đức thường sống như lìn".

kiến thức đến được không dễ, tôi thà đọc mấy bài chửi tôi thẳng mặt là tôi sai (để về sau đỡ phải đi đường cong) còn hơn là mấy cậu chỉ chỉ biết giảng đạo đức, đéo đưa ra được cái keyword nào mới lạ để mở mang kiến thức.

tôi vào thảo luận để tăng kiến giải, tăng hiểu biết, cập nhật lại kiến thức sai, chứ tôi quan tâm chó gì tới ego của các bạn. thích thì thảo luận về kiến thức, không thì cho vào ignore list, đỡ tốn thời gian của nhau.

btw, bạn haSei thì không cần phải ngại, bạn hỏi rất hợp lý có gì đâu mà phải xin lỗi "off-topic".

prescolt

Mutithread còn đặt biệt sử dung trong ứng dụng ví dụ game, ko xài share memory (shm), mỗi thread lưu một thông tin role của user, rồi game 10 cái thread vậy 1 thread chỉ duoc xử lí 1 rolename thôi à, vậy xài mutithead ko có SHM làm éo gì nữa. Trong khi có shm, thead nào cũng ko quan trong cứ móc lên rồi thao tác xong ghi xuống shm, dinh ky luu vào DB. Tôi vẫn chưa hiểu người ta viết mutithread ko dùng shm cho ngữ cãnh nào
Mà đã có SHM thì phải có mutex, ko có mutex lại dead lock. Nên tôi nói 2 thằng này là đặc tính mà một ngôn ngữ support đa luồn mạnh hay không. Còn thể loại chạy mutithread ko dùng mấy cái này ko biết là thể loại gì, ngữ cãnh nào, nếu tôi ko biết thi có thể chỉ ra, chẳng có vấn đề gì cả

Last edited: Sep 4, 2020

Nipin

Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.

mình nghĩ bạn nên đọc bài này trước: https://crystal-lang.org/reference/guides/concurrency.html

Nipin

Vậy Allocate stack hay copy data là những tác vụ của os hoặc virtual machine hoặc của thread thực thi fiber/coroutine, không ảnh hưởng gì đến cache hay data của os thread, green thread hay fiber/coroutine. Cũng không ảnh hưởng đến memory cache của core. Em chỉ muốn làm rõ điểm này.

vụ này phức tạp bỏ mẹ, security với performance luôn là hai thái cực cần trade-off. bản thân cái cpu nó cũng là một cái virtualmachine nhỏ nhỏ rồi, trong đó nó có rất nhiều kiểu optimization, nhiều khi bảo cpu/os nó xoá mà nó không xoá (map sang virtual addresses như trên nói), nhiều khi không bảo nó xoá mà vì security nó tự xoá.

cơ mà nếu bạn hỏi là việc switch fiber/coroutine trong một process thì có cần phải flush cache các kiểu không thì nói luôn là không nhé (trừ khi nó là feature của runtime)

haSei

Bạn viết mutithread mà ko xài shared memory thì tôi đặt vấn đề đơn giản như một cái ứng dụng firewall chạy đa luồn có khai bao một pool whitelist ip, ko share cho nhau vậy 32 cái thread khởi tạo 32 cái danh sách IP pool này có phải là sự tiêu tốn tài nguyên không ? rồi khi update 1 cái ip vào pool thì 32 cái thread thi nhau update, ok fine nếu chạy nhẹ nhàng ko vấn đề gì, nhưng thử nghĩ xem với một ứng dụng concurrent tầm 1tr req 1 lúc thì. Ko cần shared memory chạy muti thread thì khác gì muti process ? cứ fork ra rồi chạy, viết thread làm gì cho khổ dâm.
- Block với non blocking là cách hệ thống các thao tác trong code, bản thân ngôn ngữ làm éo gì có khái niệm ngôn ngữ blocking với nonblocking. Đây chỉ là thuật ngữ mấy thằng cuổng nodejs đưa ra, nào là nodejs no blocking balabla, bản chất vấn đề ko phải ở ngôn ngữ mà là nó thiết kế dể chay non blocking đơn giản để deploy, ko phức tạp như C hay java. Và bây giờ người ta nâng tầm thương hiệu node js là ngôn ngữ non blocking

Tại sao nodejs là single thread
, rồi xếp mấy thằng C vói java vào blocking, trong khi bản chất vấnđề là code ngu C với java nên ko làm duoc non blocking thôi.

Hở, bác phân biệt như nào là multi thread như nào là multi process vậy.
Trở lại bài toán của bác, Bác chạy 32 thread để crawl white IP, ý bác là phải tồn tài một shared variable để store và update IP một cách atomic, mình cho là bác sử dụng ReadWriteLock block đoạn update IP đi. Kiểu gì Core của bác cũng bị block, đúng hem? Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?
Mà chắc là mình hiểu sai cách bác giải bài toán nhỉ, chứ ai lại có cách làm kỳ cục thế?
Và thật ra bài toán của bác rất kinh điển, mình đang nói về cách handle dễ nhất để không phải shared memory.

prescolt

Hở, bác phân biệt như nào là multi thread như nào là multi process vậy.
Trở lại bài toán của bác, Bác chạy 32 thread để crawl white IP, ý bác là phải tồn tài một shared variable để store và update IP một cách atomic, mình cho là bác sử dụng ReadWriteLock block đoạn update IP đi. Kiểu gì Core của bác cũng bị block, đúng hem? Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?
Mà chắc là mình hiểu sai cách bác giải bài toán nhỉ, chứ ai lại có cách làm kỳ cục thế?
Và thật ra bài toán của bác rất kinh điển, mình đang nói về cách handle dễ nhất để không phải shared memory.

Đây là một chương trình tường lửa, có 32 thread, 32 thread mỗi thread pin xuống một queue NIC interface
32 thread này xử lí packet viec so sánh đia chỉ IP là việc thực hiện liên tục, ko phải là việc lâu lâu làm một lần và xử lí gói tin tới hàng triệu thì không có khái niệm chờ đi làm cái khác, 32 thread này lấy danh sách ip whitelist từ shm share chung, danh sách này được update từ thao tác cua user vào redis, và 1 trong 32 thread này cái nào cũng có thể tự nó update dinh kỳ được toàn bộ từ redis vào shm miễn sao request đi vào có destination tương ứng với whitelist IP pool và expire time của list đã quá ngưỡng define trong thread . Dead lock kiểu gì nếu khi update đã có mutex khóa cái shm lại ?
Bạn tách ra một thread để làm việc đó rồi đi làm việc khác vậy thì cái firewall vứt đi rồi. Nếu bạn ko làm việc khí thi bạn đang yêu cầu 32 thread đi lúc nào cũng phải gọi vào 1 thread duy nhất để liên tục trích xuất whitelist pool à ?

Last edited: Sep 4, 2020

haSei

Đây là một chương trình tường lửa, có 32 thread, 32 thread mỗi thread pin xuống một queue NIC interface
32 thread này xử lí packet viec so sánh đia chỉ IP là việc thực hiện liên tục, ko phải là việc lâu lâu làm một lần và xử lí gói tin tới hàng triệu thì không có khái niệm chờ đi làm cái khác, 32 thread này lấy danh sách ip whitelist từ shm share chung, danh sách này được update từ thao tác cua user vào redis, và 1 trong 32 thread này cái nào cũng có thể update dinh kỳ được toàn bộ từ redis vào shm miễn sao request đi vào có destination tương ứng với destination IP đang chạy và expire time của list đã quá ngưỡng define trong thread .
Bạn tách ra một thread để làm việc đó rồi đi làm việc khác vậy thì cái firewall vứt đi rồi

Ủa share memory ở đâu vậy bác ? Cái nào là share memory bác?

prescolt

Ủa share memory ở đâu vậy bác ? Cái nào là share memory bác?

Minh thấy bạn hỏi cái này chứng tỏ chưa bao giờ sử dụng ipcs shm bao giờ

Nipin

// ông prescolt lạc đề rồi, đâu nhất thiết phải lôi vào tới networking level.

Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?

cái calling tới một thread này bạn định làm thế nào?

prescolt

// ông prescolt lạc đề rồi, đâu nhất thiết phải lôi vào tới networking level.

cái calling tới một thread này bạn định làm thế nào?

Chỗ nào networking, đơn gian ví dụ chương trình firewall mutithread thôi cho dễ hình dung, cấp hệ điều hành, chẵng có networking nào cả

haSei

Minh thấy bạn hỏi cái này chứng tỏ chưa bao giờ sử dụng ipc shm bao giờ.

À, mình đọc thấy chữ đó rồi, bác viết là shm. À đúng rồi, mình chưa từng sử dụng Ipc shm mà bác nói bao giờ : ))))). Bác có block khi update write xuống shm hem. Khi bác block, bác phải context switch giữa các thread để update lại đúng không?

Nipin

Chỗ nào networking, đơn gian ví dụ chương trình firewall mutithread thôi cho dễ hình dung, cấp hệ điều hành, chẵng có networking nào cả

ẹc dễ hình dung với ông thôi :v

haSei

Chỗ nào networking, đơn gian ví dụ chương trình firewall mutithread thôi cho dễ hình dung, cấp hệ điều hành, chẵng có networking nào cả

Mình call tới thread stỏage, release thread để core phục vụ thread khác, sau đó thread storage sẽ notify lại mình để xử lý tiếp.
Mình quote nhầm bác @Nipin

nntgwww

vozer có một câu nói tôi thấy khá chuẩn "mấy thằng ra rả đạo đức thường sống như lìn".

kiến thức đến được không dễ, tôi thà đọc mấy bài chửi tôi thẳng mặt là tôi sai (để về sau đỡ phải đi đường cong) còn hơn là mấy cậu chỉ chỉ biết giảng đạo đức, đéo đưa ra được cái keyword nào mới lạ để mở mang kiến thức.

tôi vào thảo luận để tăng kiến giải, tăng hiểu biết, cập nhật lại kiến thức sai, chứ tôi quan tâm chó gì tới ego của các bạn. thích thì thảo luận về kiến thức, không thì cho vào ignore list, đỡ tốn thời gian của nhau.

btw, bạn haSei thì không cần phải ngại, bạn hỏi rất hợp lý có gì đâu mà phải xin lỗi "off-topic".

Nói chung việc tôi có đưa ra exp, kiến thức cho box này hay ko thì mời mọi người xét. Tôi chả nhận tài giỏi, đạo đưc gì. Biết gì thì trả lời cái đó. Ko rảnh đâu mà đi xóc xỉa language, framework, dân lập trình viên

Tại sao nodejs là single thread
))

Thấy ai sai thì tôi nói, còn hơn là thấy mà ko lên tiếng để cái chuyên đó lặp lại mãi thì cũng như lìn thôi. Lăp lại chuyên đó mãi thì cái box này còn đc mấy anh già trâu thủ dâm là 9 thôi. Có vẻ mấy anh thích box này già trâu sum vầy nói chuyên đao to búa lớn hơn là phổ cập kiến thức.

Giờ tôi có thành cừu đen, ignore list gì đấy mà cho cái box bớt tào lao bí đao thì cũng tốt

Tại sao nodejs là single thread

Last edited: Sep 4, 2020

Nipin

Mình call tới thread stỏage, release thread để core phục vụ thread khác, sau đó thread storage sẽ notify lại mình để xử lý tiếp.

ý mình là lúc bạn gọi bạn không để ý tới mấy câu lệnh bạn gọi à.

ví dụ như tôi search qua mấy bài về java, đều thấy nhắc đến locking mechanisms:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

prescolt

À, mình đọc thấy chữ đó rồi, bác viết là shm. À đúng rồi, mình chưa từng sử dụng Ipc shm mà bác nói bao giờ : ))))). Bác có block khi update write xuống shm hem. Khi bác block, bác phải context switch giữa các thread để update lại đúng không?

Vậy thì bạn chưa thực sự bao giờ viết ứng dụng đa luồng, cái bạn mô tả chỉ là một kiểu chia ra nhiều process con chuyên biệt chứ ko phải mục đích chính người ta thiết kế đa luồng.
Khi tôi write xuông shm tôi có quá trình lock, flush ,update. Thao tác cái này chỉ tốn vài mico second và 1 thread bất kỳ nào cũng tự làm được . Các thread còn lại vẫn xử lí gói tin bình thường trong khi list này bi flush ( bằng cách đọc danh sách tĩnh từ file lưu vào per thread memory) và nó ko ảnh hưởng tới hiệu năng tổng thể. Vậy nên cho dù shm bi lock hay nil thì tôi vẫn có bộ nhớ riêng của thread để lấy dữ liệu ra đối sánh với gói tin, sẽ có xác xuất dữ liệu trong thread ít hơn dữ liệu bên shm, và gói tin đi lọt, nhưng nó khó xãy ra vì phải chính xác đúng thời điểm và nếu xãy ra cũng không làm ăn gì dược với 1 packet.
nếu tôi không dùng shm mà chỉ có per thread memory thì 32 thread của tôi sẽ luôn luôn trong tình trạng lâu lâu phải flush update lại phần danh sách IP này, việc này không phù hợp yêu cầu tốc độ và tăng xác xuất lọt gói tin trong quá trình flush /update per thread memory. Nếu gọi 1 thread để lấy ra danh sách này thì tăng tải trên 1 thead xử lí cái này, 32 thread đồng nghĩa có 32 yêu cầu. nếu thread này quá tải sẽ có nguy cơ deadlock cả cụm.

Last edited: Sep 4, 2020

Nipin

lạc đề cơ mà đọc cái thread này chuẩn vãi: https://boards.4channel.org/g/thread/77553873

question:

So I tried to ask some questions at reddit and I was in shock, 120 comments and all helped me, explained things I don't understand and told me that I shouldn't give up
Meanwhile you subhumans are with crab mentality, "blackpilled" doomer faggots and incels
My eyes are open now
(this doesn't affect the political subreddits and boards on this site, they are awful both at reddit and 4chan, literally horseshoe theory)

answer:

Your thread is pretty dumb, but I'll reply anyway. Basically, r*ddit has this mentality that you should always be nice to others, and so, spoonfeeding is encouraged. It doesn't matter how retarded your question is, they're more than obliged to give you an answer, which at the same time promotes the terrible habit of expecting to have everything handed to you and not actually seeking the knowledge you are trying to get.
Despite what the rest of the internet may spout, 4chan has become pretty forgiving in recent years. General threads have a bunch of links with resources, information and such. If you seriously can't be bothered to go through the data, then you might have a mental disability, and so, deserve to be mocked/ridiculed.

cho nên đừng bảo là "chỉ có chúng mày mới thế". lại nói, lên stackoverflow hỏi ngu cũng bị block phát một thôi, đâu phải chỉ một hai nơi :-j

haSei

ý mình là lúc bạn gọi bạn không để ý tới mấy câu lệnh bạn gọi à.

ví dụ như tôi search qua mấy bài về java, đều thấy nhắc đến locking mechanisms:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

Vậy thì bạn chưa thực sự bao giờ viết ứng dụng đa luồng, cái bạn mô tả chỉ là một kiểu chia ra nhiều process con chuyên biệt chứ ko phải mục đích chính người ta thiết kế đa luồng.
Khi tôi write xuông shm tôi có quá trình lock, flush ,update. Thao tác cái này chỉ tốn vài mico second và 1 thread bất kỳ nào cũng tự làm được . Các thread còn lại vẫn xử lí gói tin bình thường trong khi list này bi flush ( bằng cách đọc danh sách tĩnh lấy ra từ cái shm lưu vào per thread memory) và nó ko ảnh hưởng tới hiệu năng tổng thể. Vậy nên cho dù shm bi lock hay nil thì tôi vẫn có bộ nhớ riêng của thread để lấy dữ liệu ra đối sánh với gói tin, sẽ có xác xuất dữ liệu trong thread ít hơn dữ liệu bên shm, và gói tin đi lọt, nhưng nó khó xãy ra và nếu xãy ra cũng không làm ăn gì dược

Mình nói rồi ấy, ví dụ 32 threads của bác đồng thời write. Tiên trình sẽ như này, một thread được quyền update xuống shm, sau đó, release block. Context switch qua thread 2, update, release block. Context switch qua thread 3, update, release block...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

zulu

Mình nói rồi ấy, ví dụ 32 threads của bác đồng thời write. Tiên trình sẽ như này, một thread được quyền update xuống shm, sau đó, release block. Context switch qua thread 2, update, release block. Context switch qua thread 3, update, release block...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

Vd đó ko thể hiện đc điều mà bác ấy nói vì tất tần tật đc redis lo rồi. Bác ấy cứ read write thoả mái thôi. Tóm lại vd đó ko thể hiện rõ vd về sử dụng shared memory.

via nextVOZ for iPhone

prescolt

Mình nói rồi ấy, ví dụ 32 threads của bác đồng thời write. Tiên trình sẽ như này, một thread được quyền update xuống shm, sau đó, release block. Context switch qua thread 2, update, release block. Context switch qua thread 3, update, release block...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

Bạn nói gì mình không hiểu gì cả

Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?

Bạn viết cái này mình đọc lại cũng không hiểu, nói thật là mình thấy bạn như đang nói đang search google vậy. Thread mà bạn call request y như gọi Rest API nhỉ, nghe giống như lập trình theo mô hình micro service kiểu async hơn.

haSei

ý mình là lúc bạn gọi bạn không để ý tới mấy câu lệnh bạn gọi à.

ví dụ như tôi search qua mấy bài về java, đều thấy nhắc đến locking mechanisms:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

À, ý của bác là trường hợp này vẫn còn bị block khi chờ message từ thread storage đúng không. Đương nhiên rồi, mình đang lấy ví dụ về structure non share memory cho bác prescot thôi.

Nếu là java mình dùng Future, nếu là golang thì có channel.

Mỗi architect đều có mạnh yếu riêng, nhưng bác biết có nhiều cách khác nhau để handle concurrency đúng không. Không bắt buộc phải có shm.

prescolt

Vd đó ko thể hiện đc điều mà bác ấy nói vì tất tần tật đc redis lo rồi. Bác ấy cứ read write thoả mái thôi. Tóm lại vd đó ko thể hiện rõ vd về sử dụng shared memory.

via nextVOZ for iPhone

Không ai đọc redis liên tục cả bạn, chẳng lẽ cứ 1 request đọc redis 1 lần, ko ghi vào memory cái danh sách Smember của redis share cho nhau xài thì vài chục thread thi nhau đọc vào redis, redis chết thì mình chết theo à ?

Nipin

Mình nói rồi ấy, ví dụ 32 threads của bác đồng thời write. Tiên trình sẽ như này, một thread được quyền update xuống shm, sau đó, release block. Context switch qua thread 2, update, release block. Context switch qua thread 3, update, release block...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

cái thread chứa data của bạn lúc này đóng vai trò là shared memory rồi :v

mà giải pháp của bạn thường người ta gọi là actor model, cũng là một cách giải quyết của concurrent.

cơ mà tuỳ thuộc bài toán cụ thể mà cách này ngon hơn cách kia, actor model nó tương tác với nhau bằng message passing, message mà nhỏ thì ok, nhưng nhiều bài toán xử lý dữ liệu lớn (number crunching) thì rõ ràng shared memory hiệu quả hơn hẳn.

haSei

Bạn nói gì mình không hiểu gì cả

Bạn viết cái này mình đọc lại cũng không hiểu, nói thật là mình thấy bạn như đang nói đang search google vậy. Thread mà bạn call request y như gọi Rest API nhỉ, nghe giống như lập trình theo mô hình micro service kiểu async hơn.

Bác ơi, không đâu. Nó là kiểu event driven kinh điển thôi.
Khi bác update, bác phải block, đúng không. 32 thread update đồng thời, bác phải thực hiện 32 context switch để có thể update. Bác hiểu context switching đúng hem. Tức là, bác phải update tuần tự, không thể song song. Bác cũng không thể read từ local thread đơn thuần, thưa bác. Mà bác phải đi so sánh xem có action update không, bác mới được phép read từ local.

prescolt

Bác ơi, không đâu. Nó là kiểu event driven kinh điển thôi.
Khi bác update, bác phải block, đúng không. 32 thread update đồng thời, bác phải thực hiện 32 context switch để có thể update. Bác hiểu context switching đúng hem. Tức là, bác phải update tuần tự, không thể song song. Bác cũng không thể read từ local thread đơn thuần, thưa bác. Mà bác phải đi so sánh xem có action update không, bác mới được phép read từ local.

đã SHM thì làm gì có chuyện 32 thằng update đồng thời, thằng nào update thi mutex lock lại và thao tac, trong thời gian thao tác mấy thằng kia vẫn chạy bình thường chứ có gì mà tuần tự ?

haSei

Đúng

cái thread chứa data của bạn lúc này đóng vai trò là shared memory rồi :v

mà giải pháp của bạn thường người ta gọi là actor model, cũng là một cách giải quyết của concurrent.

cơ mà tuỳ thuộc bài toán cụ thể mà cách này ngon hơn cách kia, actor model nó tương tác với nhau bằng message passing, message mà nhỏ thì ok, nhưng nhiều bài toán xử lý dữ liệu lớn (number crunching) thì rõ ràng shared memory hiệu quả hơn hẳn.

Đúng, đó là actor, xem ra bác biết nó đúng không. Nhưng nó không share memory, 32 thread kia không cần care race conditions hoặc tương tự. Việc update của mình cũng không cần context switch. Mình đang lấy ví dụ về không cần share memory.

Nipin

quay lại thì concurrent không phải là multi-threaded. dù là có event loop thì trong cùng một thời gian chỉ có đúng một cái thread được thực thi, lúc đó thì đúng là không cần quan tâm lock hay cái quái gì cả.
multi threaded (multi cpu core) thì cùng một lúc có thể có 2 task cùng access một đoạn dữ liệu, gây ra race condition hoặc deadlock, lúc đó cần có cơ chế để giải quyết vấn đề này. và cái này là bắt buộc cần có luôn, dù rằng bạn có dùng actor model hay không (nhưng ngôn ngữ nó thể ẩn đi không cho phép bạn truy cập cái này, aka non feature).

zulu

Không ai đọc redis liên tục cả bạn, chẳng lẽ cứ 1 request đọc redis 1 lần, ko ghi vào memory cái danh sách Smember của redis share cho nhau xài thì vài chục thread thi nhau đọc vào redis, redis chết thì mình chết theo à ?

Ok nãy đọc ko kỹ . Vậy thì bạn hẳn phải có cơ chế lock đồng bộ khi có các vụ ghi vô redis bạn cũng phải cập nhật trên shared memory đúng ko? Nếu ko có thì mất tính data consistency

via nextVOZ for iPhone

haSei

đã SHM thì làm gì có chuyện 32 thằng update đồng thời, thằng nào update thi mutex lock lại và thao tac, trong thời gian thao tác mấy thằng kia vẫn chạy bình thường chứ có gì mà tuần tự ?

Thì đấy bác. Bài toán 32 thằng muốn update, mutex có phải sẽ chỉ cho một thằng chạy, mấy 31 threas kia bị block lại đúng không.

haSei

quay lại thì concurrent không phải là multi-threaded. dù là có event loop thì trong cùng một thời gian chỉ có đúng một cái thread được thực thi, lúc đó thì đúng là không cần quan tâm lock hay cái quái gì cả.
multi threaded (multi cpu core) thì cùng một lúc có thể có 2 task cùng access một đoạn dữ liệu, gây ra race condition hoặc deadlock, lúc đó cần có cơ chế để giải quyết vấn đề này. và cái này là bắt buộc cần có luôn, dù rằng bạn có dùng actor model hay không (nhưng ngôn ngữ nó thể ẩn đi không cho phép bạn truy cập cái này, aka non feature).

Multi thread không hản là hai thread cùng access một đoạn code. Như mình nói hồi nãy, sử dụng event driven hoặc như function programming immutable hết là xong.

Nipin

Thì đấy bác. Bài toán 32 thằng muốn update, mutex có phải sẽ chỉ cho một thằng chạy, mấy 31 threas kia bị block lại đúng không.

à không, mutex thường chỉ xảy ra lúc ghi thôi, với lại tuỳ loại mutex, nó không block hẳn đâu.
với lại cũng tuỳ cách bạn thiết kế nữa, dùng 1 channel hay dùng nhiều channel kết hợp để lưu shared memory.

prescolt

Ok nãy đọc ko kỹ . Vậy thì bạn hẳn phải có cơ chế lock đồng bộ khi có các vụ ghi vô redis bạn cũng phải cập trên trên shared memory đúng ko? Nếu ko có thì mất tính data consistency

via nextVOZ for iPhone

Ghi vào redis là phía tool hay frontend, phần mềm ko có write gì trong này cả, chỉ đọc thôi.
Vài khi đọc thì sẽ flush shared memory, thread nào nhận packet có destination 1.1.1.1 trước và expire time tới hạn thì sẽ update shared memory pool tương ứng 1.1.1.1, trong qua trình update thì mấy thread còn lại nếu cũng nhận 1.1.1.1 thì dữ liệu sẽ rỗng luc đó thì sẽ có bảng memory của riêng thread đọc từ file lên, như vậy sẽ giải quyết được vấn đề block ở shared mem. Nếu lúc nào cũng đọc file thì block cao hơn, và đọc từ file thì không có timeout như đọc từ TCP, io mà dẹo thì rất dễ dead lock

nntgwww

Chắc anh Nip ignore tôi rồi nên quote cung ko dc g

Tại sao nodejs là single thread
)

Có thể anh chơi 4chan nhiều nên văn hoá đó anh quen, nên cmt nào đó lại xen đéo, dm . Sau này bị tủ lanh chả chỉ thẳng mặt.

Nhưng đây là voz ko phải 4chan. Mỗi nơi mỗi văn hoá khác nhau. Theo anh nghĩ bộ sậu tủ lạnh có mong muốn biến nó thành 4chan thứ 2 đâu? để chửi bới, phỉ báng, post bài ko có tính thảo luận, thượng đẳng cho nó giống văn hoá bún chửi 4chan.

Ngay cả cho dù câu hỏi này nó có thể tìm thấy trên google nhưng anh nghĩ newbie hiểu thực sự thế nào. và có câu hỏi nào có cuộc tranh luận giữa người Việt ntn?. Như anh + prescot mong muốn người khác tự chủ động tìm kiếm thông tin trên mạng thì giờ cũng dung chính cái 2pic này làm đất dụng võ còn gì.

Ko có những thằng hỏi ngu newbie trên thế giới này thì chắc stack overflow cung ko tràn ngập thông tin để mấy anh search

Tại sao nodejs là single thread
)).

Last edited: Sep 4, 2020

Nipin

Multi thread không hản là hai thread cùng access một đoạn code. Như mình nói hồi nãy, sử dụng event driven hoặc như function programming immutable hết là xong.

immutable của FP là language feature, mỗi lần update data là nó tạo copy mới (tất nhiên nó có thể share một phần dữ liệu cũ), trong nhiều bài toán thì nó là overhead không thể chấp nhận được. cho nên implement language runtime không ai dùng immutable structure cả.

cơ mà dù là dùng immutable tất cả nhé, thì cái pointer/reference tới đoạn dữ liệu ấy có phải là mutable không, lockup address có phải là mutable không? cuối cùng thì bên dưới đáy nó vẫn phải implement mấy cái ở trên đang thảo luận thôi.

haSei

à không, mutex thường chỉ xảy ra lúc ghi thôi, với lại tuỳ loại mutex, nó không block hẳn đâu.
với lại cũng tuỳ cách bạn thiết kế nữa, dùng 1 channel hay dùng nhiều channel kết hợp để lưu shared memory.

Ừa, nó sẽ thường xảy ra lúc ghi, nên mình mới nói về bài toán update cùng lúc.
Ngoài ra, về bài toán read, thì phải check xem có đang lock update không thì mới read local được.

Còn bài toán của bác Prescot, thì thường người ta dùng CAS thôi. Chứ chẳng ai dùng mutex block cả. Tuy nhiên, mình đang muốn lấy ví dụ, về cách có thể không cần share memory.

Mà không block hẳn là sao bác nhỉ.

haSei

immutable của FP là language feature, mỗi lần update data là nó tạo copy mới (tất nhiên nó có thể share một phần dữ liệu cũ), trong nhiều bài toán thì nó là overhead không thể chấp nhận được. cho nên implement language runtime không ai dùng immutable structure cả.

cơ mà dù là dùng immutable tất cả nhé, thì cái pointer/reference tới đoạn dữ liệu ấy có phải là mutable không, lockup address có phải là mutable không? cuối cùng thì bên dưới đáy nó vẫn phải implement mấy cái ở trên đang thảo luận thôi.

Mỗi bài toán có một architect khác nhau phù hơp. Vấn đề là, bác Prescot cho rằng không tồn tại Concurrency non share memory.
Còn immutable của FP không phải như bác nói đâu, nó là cách thiết kế code thôi, cố gắng chuyển dịch code từ xử lý data chung thành những process, mỗi process là một pure function không gây side effect mà chỉ quan tâm tới input và output. Nó không dùng cho mọi bài toán, nhưng là một cách thiết kế.
Ví dụ, như bài toán của bác Prescot, FP sẽ thiết kế như này. Read ips từ Redis, gọi function update, chờ kết quả, call function save redis với kết quả nhận được.
Điểm mạnh của thiết kế này là tăng tính independent giữa các thread, thuận tiện để xử lý parralel hơn. Bác biết mà, share memory là kẻ thù của parralel.
Parralel chứ không phải Concurrency.

haSei

Ghi vào redis là phía tool hay frontend, phần mềm ko có write gì trong này cả, chỉ đọc thôi.
Vài khi đọc thì sẽ flush shared memory, thread nào nhận packet có destination 1.1.1.1 trước và expire time tới hạn thì sẽ update shared memory pool tương ứng 1.1.1.1, t rong qua trình update thì mấy thread còn lại nếu cũng nhận 1.1.1.1 thì dữ liệu sẽ rỗng luc đó thì sẽ có bảng memory của riêng thread đọc từ file lên, như vậy sẽ giải quyết được vấn đề block ở shared mem. Nếu lúc nào cũng đọc file thì block cao hơn, và đọc từ file thì không có timeout như đọc từ TCP, io mà dẹo thì rất dễ dead lock

Bác có biết thiên kiến của bác là gì không? Bác cho răng một Architect là tốt nhất, và bác cũng đang lấy ví dụ về thứ thân thuộc với bạn nhất, một bài toán mà bác hiểu rõ về requirement để lấy ví dụ, đúng không? Và như mình đã nói, có rất nhiều cách để handle concurrency. Không nhất thiết phải share memory.
Và câu chuyện gom lại là về cách thiết kế thôi. Bác Nipin nói bác đi lạc để ngay từ đầu đó, mình cũng muốn hầu với bác.
Trở lại với bài toán, block cao hơn có nghĩa là gì? Vì sao nếu mấy thread còn lại nhận 1.1.1.1 thì dữ liệu sẽ rỗng? Bảng memory đọc từ file lên, file đó bác lưu ở đâu vậy? Nếu mình muốn 64 thread là phải tạo ra 64 file à, vì sao làm vậy thì giải quyết được block từ share mem? Share mem làm sao bị block được, ý bác là những action với share mem đó hở? Action cự thể la read hay write?
Bài toán của mình là 32 thread cùng update cùng lúc, vì mình không hiểu bác đang nói gì, nên mình gom lại bài toán như vậy. Lúc đó, bác xử lý như nào?

haSei

Còn nếu ý bác đang nói về share memory mà bác share, thì thưa bác, có hai điều.
Thứ nhất, đó là share memory của system, không phải là share memory khi thiết kế concurrency.
Thứ hai, Golang là multiple thread language, và architect của nó không có share memory ở system bác ạ. Mỗi goroutine không dùng chung stack, thưa bác.

prescolt

Ừa, nó sẽ thường xảy ra lúc ghi, nên mình mới nói về bài toán update cùng lúc.
Ngoài ra, về bài toán read, thì phải check xem có đang lock update không thì mới read local được.

Còn bài toán của bác Prescot, thì thường người ta dùng CAS thôi. Chứ chẳng ai dùng mutex block cả. Tuy nhiên, mình đang muốn lấy ví dụ, về cách có thể không cần share memory.

Mà không block hẳn là sao bác nhỉ.

Về nguyên tắc update cái gì liên quan tới network, file là có io block, mutex lock tài nguyên A thì các thread khác sẽ không truy cập được trong thời gian đó, tức là nó sẽ sleep, để giải quyết vấn đề này vói nhưng share mem liên quan tới io block thì có một giải pháp tôi thiết kế phải sét loại giá trị đó hạn sử dụng theo timestamp của OS để tránh update liên tuc
- Các thread còn lại tránh bi sleep waiting khi A đang bi mutex lock thi sử dụng hàm có sẵn trong linux kernel để check có đang lock hay ko https://elixir.bootlin.com/linux/v4.4.137/source/include/linux/mutex.h#L128
, nếu lock thì thread đọc từ file lên, file có thể nằm trong RAm disk hay bất kỳ cái nào có io cao.
mà những cái này thi mấy ngôn ngữ cấp cao không thể làm được

Tại sao nodejs là single thread

haSei

Về nguyên tắc update cái gì liên quan tới network, file là có io block, mutex lock tài nguyên A thì các thread khác sẽ không truy cập được trong thời gian đó, tức là nó sẽ sleep, để giải quyết vấn đề này vói nhưng share mem liên quan tới io block thì có một giải pháp tôi thiết kế phải sét loại giá trị đó hạn sử dụng theo timestamp của OS để tránh update liên tuc
- Các thread còn lại tránh bi sleep waiting khi A đang bi mutex lock thi sử dụng hàm có sẵn trong linux kernel để check có đang lock hay ko https://elixir.bootlin.com/linux/v4.4.137/source/include/linux/mutex.h#L128
, nếu lock thì thread đọc từ file lên, file có thể nằm trong RAm disk hay bất kỳ cái nào có io cao.
mà những cái này thi mấy ngôn ngữ cấp cao không thể làm được

Tại sao nodejs là single thread

Ồ, tức là bài toán của bác là. Mình sẽ tóm gọn bài toán này lại. Bác muốn xử lý concurrent để Read một trạng thái whiteIP với delay time nhỏ nhất, để đảm bảo Read liên tục, Write sẽ rất hạn chế. Đúng không.
Lời giải của bác, là read phải check lock, nếu lock thì phải đọc từ file lên.
Vậy, bác update file local như nào hở bác? Mỗi lần thực thiện process đều compare với srm để update, hay mỗi lần check lock xong phải đọc từ file local, sau đó quay lại đọc từ srm để update local file, hay thực hiện cron update?
Ấy bác ạ, mấy ngôn ngữ cấp cao làm giúp mình phần check lock rồi bác ạ. Và các bài toán của ngôn ngữ cấp cao khác bài toán mà bác giải quyết nhiều lắm. TUy nhiên, em vẫn muốn hầu bác.

prescolt

Ồ, tức là bài toán của bác là. Mình sẽ tóm gọn bài toán này lại. Bác muốn xử lý concurrent để Read một trạng thái whiteIP với delay time nhỏ nhất, để đảm bảo Read liên tục, Write sẽ rất hạn chế. Đúng không.
Lời giải của bác, là read phải check lock, nếu lock thì phải đọc từ file lên.
Vậy, bác update file local như nào hở bác? Mỗi lần thực thiện process đều compare với srm để update, hay mỗi lần check lock xong phải đọc từ file local, sau đó quay lại đọc từ srm để update local file, hay thực hiện cron update?
Ấy bác ạ, mấy ngôn ngữ cấp cao làm giúp mình phần check lock rồi bác ạ. Và các bài toán của ngôn ngữ cấp cao khác bài toán mà bác giải quyết nhiều lắm. TUy nhiên, em vẫn muốn hầu bác.

shm có thì xài, ko có thì đọc từ file. local file có nội dung song song với redis được ghi từ service khác độc lập . Đọc tự file lên cũng chỉ mất vài chục của phần triệu s và cũng chỉ đọc khi mutex_lock, và đọc xong thì cũng lưu vào thread mem để xài lại.

Last edited: Sep 4, 2020

haSei

shm có thì xài, ko có thì đọc từ file. local file có nội dung song song với redis được ghi từ service khác độc lập . Đọc tự file lên cũng chỉ mất vài chục của phần triệu s và cũng chỉ đọc khi mutex_lock

Thật ra

shm có thì xài, ko có thì đọc từ file. local file có nội dung song song với redis được ghi từ service khác độc lập . Đọc tự file lên cũng chỉ mất vài chục của phần triệu s và cũng chỉ đọc khi mutex_lock, và đọc xong thì cũng lưu vào thread mem để xài lại.

Đọc xong lưu vào thread mem để xài lại là sao bác nhỉ, bác đọc từ file ra rồi lưu lại vào file à. Service khác độc lâp tức là phải cron task đúng khônng, hay là listen event khi có write vào redis.
Và bài toán chính ở đây là, làm sao để đọc nhanh nhất có thể thôi, đúng hem bác.

nguyenna

Có thể dùng một ngôn ngữ C hay Java để viết mô phỏng lại event loop của node js muc đích concurrency mà chạy được đa luồng. Mutithread, mỗi thread muti concurrency, non blocking. Hàng mì ăn liền thì nó tới đó thôi

vâng nói chung về mặt nguyên lý, khi nắm đc mô hình thì có thể mô phỏng lại được. ví dụ ở đây NodeJS phải lưu ý mấy cái run-to-complete, scheduling, message queues cho workers, triển khai cụ thể ra thì phải xem tính năng của host language. đoán chừng cũng nhiều việc. Với mình thì tinh thần là right tool right job như bác gì nói ở trên. Mô hình concurrency, languages/frameworks hỗ trợ cũng đầy ra.
ps. chém với các bác cho vui chứ mình amateur

XinClipBiBan

mà những cái này thi mấy ngôn ngữ cấp cao không thể làm được

Tại sao nodejs là single thread

  • Trên đời nàycó bao nhiêu ngôn ngữ bật cao?
  • Anh biết đc bao nhiêu, đã code đc bao nhiêu ngôn ngữ?
  • Anh từng làm bao nhiêu hệ thống, bao nhiêu cấu trúc phần cứng, mềm?

Tôi không biết ông anh trình thế nào, nhưng phát biểu câu này thì ông anh tự phụ và hẹp hòi lắm

Tại sao nodejs là single thread

prescolt

  • Trên đời nàycó bao nhiêu ngôn ngữ bật cao?
  • Anh biết đc bao nhiêu, đã code đc bao nhiêu ngôn ngữ?
  • Anh từng làm bao nhiêu hệ thống, bao nhiêu cấu trúc phần cứng, mềm?

Tôi không biết ông anh trình thế nào, nhưng phát biểu câu này thì ông anh tự phụ và hẹp hòi lắm

Tại sao nodejs là single thread

Đây có phải bài trắc nghiệm các câu hỏi mẩu giáo không.

via theNEXTvoz for iPhone

prescolt

Thật ra

Đọc xong lưu vào thread mem để xài lại là sao bác nhỉ, bác đọc từ file ra rồi lưu lại vào file à. Service khác độc lâp tức là phải cron task đúng khônng, hay là listen event khi có write vào redis.
Và bài toán chính ở đây là, làm sao để đọc nhanh nhất có thể thôi, đúng hem bác.

Là luu vào bộ nhớ của riêng cái thread đó. Service khác tu frontend ghi vào là thao tác của user. Sau khi ghi vào redis hay file thì thôi là xong của frontend, phần còn lại là firewall tự cập nhật, sẽ ko có event gì cả

via theNEXTvoz for iPhone

zulu

Là luu vào bộ nhớ của riêng cái thread đó. Service khác tu frontend ghi vào là thao tác của user. Sau khi ghi vào redis hay file thì thôi là xong của frontend, phần còn lại là firewall tự cập nhật, sẽ ko có event gì cả

via theNEXTvoz for iPhone

Vấy phía 32 threads đọc , thím làm sao để đồng bộ data thay đổi ?

Đọc thì có vẻ data của các chấp nhận chuyện xảy ra inconsistent ( trong thời gian chờ expire của bác) giữa dữ liệu thật trên redis và cache trên mem của từng thread. Vì theo bác nói tác vụ ghi và đọc ko đồng bộ respect lẫn nhau

Last edited: Sep 5, 2020

haSei

Thật ra

Đọc xong lưu vào thread mem để xài lại là sao bác nhỉ, bác đọc từ file ra rồi lưu lại vào file à. Service khác độc lâp tức là phải cron task đúng khônng, hay là listen event khi có write vào redis.
Và bài toán chính ở đây là, làm sao để đọc nhanh nhất có thể thôi, đúng hem bác.

Thôi được rồi, mình nói mà bác không rep nữa thì thôi vậy.

Điểm yếu của share memory là, bác phải handle được bài toán deadlock, race condition, live lock..., Không thể chạy parallel, vì bác bị phụ thuộc vào share memory, bắt buộc các tác vụ của bác phải chạy trên một thread. Xu hướng xử lý performance bây giờ là, tối ưu core, cách hiện thực là, chia task nhỏ ra không phụ thuộc lẫn nhau, để có thể phân đều cho core xử lý. Ví dụ một tác vụ 3 bước trên cùng một thread, thì chỉ có một core xử lý, nhưng nếu tách tác vụ đó ra 3 step riêng biệt, phân vào 3 thread, để 3 thread xử lý, thì có khả năng bác sẽ được 3 core xử lý. Ví dụ như action firewall của bác, có 3 step là xử lý trước khi đọc shm, đọc shm, và xử lý sau khi đọc shm. Nếu bác không dùng shm, bác có thể chia nó ra làm 3 task riêng biệt.
Để thiết kế hoàn chỉnh thì rất dài, nên mình đã đưa cách đơn giản, dựa theo idea trên, đẩy tác vụ xử lý storage vào một thread riêng.
Nhưng điểm chính yếu mình muốn nói với bác, đó là tồn tại architect concurrency non share memory. Và điểm thứ hai là, không có công nghệ nào là tốt nhất.
Nên mong bác đừng áp đặt, đừng chê bai, cũng đừng tự cho mình là đúng. Học hỏi cùng phát triển mới là cách để mỗi người làm công nghệ phát triển.

prescolt

Vấy phía 32 threads đọc , thím làm sao để đồng bộ data thay đổi ?

Tôi thiết kế kiểu dữ liệu như sau
Ip destination: a sẽ có acl là b
Acl b có một time expire là 30s từ lần update trước đó theo tham chiếu time của os
Khi gói tin có des là a vào thì sẽ tham chiếu acl b, nếu thơi gian trong b lúc tham chiếu đã expire thì flush và update smember từ redis và ghi vào shm, ngược lại nếu chưa quá hạn thì lấy ip ra và đối sánh với a. Nếu acl b trong suốt thời gian ko có packet a đi vào thì sẽ ko bao giờ cần phải update vì acl b không được tham chiếu

via theNEXTvoz for iPhone

prescolt

Thôi được rồi, mình nói mà bác không rep nữa thì thôi vậy.

Điểm yếu của share memory là, bác phải handle được bài toán deadlock, race condition, live lock..., Không thể chạy parallel, vì bác bị phụ thuộc vào share memory, bắt buộc các tác vụ của bác phải chạy trên một thread. Xu hướng xử lý performance bây giờ là, tối ưu core, cách hiện thực là, chia task nhỏ ra không phụ thuộc lẫn nhau, để có thể phân đều cho core xử lý. Ví dụ một tác vụ 3 bước trên cùng một thread, thì chỉ có một core xử lý, nhưng nếu tách tác vụ đó ra 3 step riêng biệt, phân vào 3 thread, để 3 thread xử lý, thì có khả năng bác sẽ được 3 core xử lý. Ví dụ như action firewall của bác, có 3 step là xử lý trước khi đọc shm, đọc shm, và xử lý sau khi đọc shm. Nếu bác không dùng shm, bác có thể chia nó ra làm 3 task riêng biệt.
Để thiết kế hoàn chỉnh thì rất dài, nên mình đã đưa cách đơn giản, dựa theo idea trên, đẩy tác vụ xử lý storage vào một thread riêng.
Nhưng điểm chính yếu mình muốn nói với bác, đó là tồn tại architect concurrency non share memory. Và điểm thứ hai là, không có công nghệ nào là tốt nhất.
Nên mong bác đừng áp đặt, đừng chê bai, cũng đừng tự cho mình là đúng. Học hỏi cùng phát triển mới là cách để mỗi người làm công nghệ phát triển.

Race condition và dead lock là do bạn code không đúng đẻ dead lock, đó ko phải là vướng mắt. Người ta sinh ta mutex đẻ tranh race condition và việc bạn khoá mutex không đúng làm deadlock là vấn đề chủ quan không phải giới hạn ky thuật. Nếu bạn chạy chỉ một thread thì với ứng dụng cấp hệ thống như tôi trình bày thì sẽ ko thể nào sủ dụng hết được interrupt và numa node. Đây là sản phẩm đang chạy production, có user chứ ko phải tôi nghĩ ra
Ví du trang mxh này, dĩ nhiên fw chay nhiều trang chứ ko phải một
Lazi.vn traffic một tháng 5 triêu kh dang sử dụng fw ở trên. Nói chung khi nào ban viết ứng dụng chạy dưới hệ thống cap thap thì bạn mới hiểu kiểu chia nhỏ micro, nhiều dependence càng làm cho hệ thống sinh nhiêu single point of failture. Là việc không cần thiết

via theNEXTvoz for iPhone

zulu

Tôi thiết kế kiểu dữ liệu như sau
Ip destination: a sẽ có acl là b
Acl b có một time expire là 30s từ lần update trước đó theo tham chiếu time của os
Khi gói tin có des là a vào thì sẽ tham chiếu acl b, nếu thơi gian trong b lúc tham chiếu đã expire thì flush và update smember từ redis và ghi vào shm, ngược lại nếu chưa quá hạn thì lấy ip ra và đối sánh với a. Nếu acl b trong suốt thời gian ko có packet a đi vào thì sẽ ko bao giờ cần phải update vì acl b không được tham chiếu

via theNEXTvoz for iPhone

Ok thím.

Hiện tại trên cache data của thread đọc chứa 1 entry ip a có acl là b như thím nói nha. Và còn tận 20s nữa mới expire.

Ngay lúc đó bên write thì thay đổi remove 1 entry này đi. Vì bác ko có cơ chế nào đồng bộ cho bên read. Nên bọn read phải sau khi expire mới thấy đc sự thay đổi.

Vậy thì có vẻ data của các chấp nhận chuyện xảy ra inconsistent ( trong thời gian chờ expire của bác) giữa dữ liệu thật trên redis và cache trên mem của từng thread. Vì theo bác nói tác vụ ghi và đọc ko đồng bộ respect lẫn nhau

via nextVOZ for iPhone

prescolt

Ok thím.

Hiện tại trên cache data của thread chứa 1 entry ip a có acl là b như thím nói nha. Và còn tận 20s nữa mới expire.

Ngay lúc đó bên write thì thay đổi remove 1 entry này đi. Vì bác ko có cơ chế nào đồng bộ cho bên read. Nên bọn read phải sau khi expire mới thấy đc sự thay đổi.

Vậy thì có vẻ data của các chấp nhận chuyện xảy ra inconsistent ( trong thời gian chờ expire của bác) giữa dữ liệu thật trên redis và cache trên mem của từng thread. Vì theo bác nói tác vụ ghi và đọc ko đồng bộ respect lẫn nhau

via nextVOZ for iPhone

Chính xác là như vậy max là 30s, tuy nhiên nếu user vừa add hay vùa xoá ngay lúc có traffic đi vào và đúng time expire thì nó tức thời, nên 30s chỉ là lâu nhất, thúc tế mình cho 5s vẫn ok vẫn mượt mà nhưng mình không thích day he thong tới hạn, và kh chấp nhận nó

Tại sao nodejs là single thread

via theNEXTvoz for iPhone

haSei

Vấy phía 32 threads đọc , thím làm sao để đồng bộ data thay đổi ?

Đọc thì có vẻ data của các chấp nhận chuyện xảy ra inconsistent ( trong thời gian chờ expire của bác) giữa dữ liệu thật trên redis và cache trên mem của từng thread. Vì theo bác nói tác vụ ghi và đọc ko đồng bộ respect lẫn nhau

Cái này thím ấy có nói rồi

Race condition và dead lock là do bạn code không đúng đẻ dead lock, đó ko phải là vướng mắt. Người ta sinh ta mutex đẻ tranh race condition và việc bạn khoá mutex không đúng làm deadlock là vấn đề chủ quan không phải giới hạn ky thuật. Nếu bạn chạy chỉ một thread thì với ứng dụng cấp hệ thống như tôi trình bày thì sẽ ko thể nào sủ dụng hết được interrupt và numa node. Đây là sản phẩm đang chạy production, có user chứ ko phải tôi nghĩ ra
Ví du trang này
Lazi.vn traffic một tháng 5 triêu kh dang sử dụng fw ở trên

via theNEXTvoz for iPhone

Vướng mắc chứ bác, vì race condition, dead lock..., nó không nằm ở những tác vụ đơn giản, mà có những case phức tạp hơn nhiều, mà ở đó, để handle tốt, bác sẽ phải đánh đổi performance, cả ở sản phẩm và thời gian release sản phẩm. Thứ hai, là khả năng scale up, khi hệ thống bác bị phụ thuộc lẫn nhau, logic xử lý cồng kềnh ( ở đây là logic xử lý race condition...), scale up là tốn effort. Scale up tức là thêm logic á, thêm requirements á, chứ mình chưa nói đến scale hệ thống.
Nên người ta mới nghĩ ra những phương pháp giảm bớt sự phụ thuộc.
Bác đừng định kiến nhé, môt giải pháp chạy tốt cho một ứng dụng 5tr user chưa chắc dùng được cho ứng dụng khác. Ngay từ đầu mình đã nói concurrency share memory là một trong những cách thực thi concurrency mà. Mình không phủ nhận nó. Nhưng vẫn còn những giải pháp khác. Nên mong bác đừng đưa ra một thực tiễn để loại bỏ hoàn toàn lý thuyết.

zulu

Chính xác là như vậy max là 30s, tuy nhiên nếu user vừa add hay vùa xoá ngay lúc có traffic đi vào và đúng time expire thì nó tức thời, nên 30s chỉ là lâu nhất, thúc tế mình cho 5s vẫn ok vẫn mượt mà nhưng mình không thích day he thong tới hạn, và kh chấp nhận nó

Tại sao nodejs là single thread

via theNEXTvoz for iPhone

oki thím.

prescolt

Cái này thím ấy có nói rồi

Vướng mắc chứ bác, vì race condition, dead lock..., nó không nằm ở những tác vụ đơn giản, mà có những case phức tạp hơn nhiều, mà ở đó, để handle tốt, bác sẽ phải đánh đổi performance, cả ở sản phẩm và thời gian release sản phẩm. Thứ hai, là khả năng scale up, khi hệ thống bác bị phụ thuộc lẫn nhau, logic xử lý cồng kềnh ( ở đây là logic xử lý race condition...), scale up là tốn effort. Scale up tức là thêm logic á, thêm requirements á, chứ mình chưa nói đến scale hệ thống.
Nên người ta mới nghĩ ra những phương pháp giảm bớt sự phụ thuộc.
Bác đừng định kiến nhé, môt giải pháp chạy tốt cho một ứng dụng 5tr user chưa chắc dùng được cho ứng dụng khác. Ngay từ đầu mình đã nói concurrency share memory là một trong những cách thực thi concurrency mà. Mình không phủ nhận nó. Nhưng vẫn còn những giải pháp khác. Nên mong bác đừng đưa ra một thực tiễn để loại bỏ hoàn toàn lý thuyết.

Tôi ko biết ngôn ngữ ngoài c hay java ra khi xủ li mutex cost bao lâu, với c chỉ tầm 2x ns là trên các cpu gọi là củ như x5600 . Trên cpu đời mới có khi còn thấp hơn. Và theo như hệ thống hiện tai tôi thấy hiêu năng còn rất nhiều, nếu ko dùng ipc shm chi dung
Thread mem thì redis sẽ phải chạy nhiều hơn, redis độ trễ tâm 1ms vẫn cao nếu gọi liên tục. Và dù cho có chạy môt thread riêng đẻ làm việc trên thì vơi c củng phải dùng shm và ipc. Vậy mấy ngon ngữ cấp cao hơn cho phép thread nói chuyện với nhau mà ko có ipc shm à ?

via theNEXTvoz for iPhone

quandaso

Trả lời câu hỏi của chủ thread, js thực sự là single thread. Để khắc vụ hạn chế của single thread thì node nó có thêm cái node cluster, với message API giữa master và slave rất clear và dễ sử dụng.
CÓ 1 lời khuyên với chủ thread là thực sự ko cần quan tâm nhiều đến mấy ông trên tranh luận đâu, vì bài toán lập trình concurrent thực sự là bài toán quá khó, lập trình viên bình thường khó mà có thể nắm đc và giải quyết đc hết vấn đề. Nên tìm hiểu mô hình phổ biến hơn và ít đau đầu hơn là dùng đó là multiple process (master và workers)

Last edited: Sep 5, 2020

jvinhit

Thực sự JS là single thread chứ còn gì nữa ông, còn về background thread hay những thread chạy ngầm khác của trình duyệt là một kĩ thuật khác, và cách tương tác trao đổi dữ liệu qua lại cũng là một kĩ thuật khác.

Còn cơ chế hoạtđộng của JS tại sao ko bị block vân vân và mây mây thì base trên cơ chế event loop.

prescolt

Trả lời câu hỏi của chủ thread, js thực sự là single thread. Để khắc vụ hạn chế của single thread thì node nó có thêm cái node cluster, với message API giữa master và slave rất clear và dễ sử dụng.
CÓ 1 lời khuyên với chủ thread là thực sự ko cần quan tâm nhiều đến mấy ông trên tranh luận đâu, vì bài toán lập trình concurrent thực sự là bài toán quá khó, lập trình viên bình thường khó mà có thể nắm đc và giải quyết đc hết vấn đề. Nên tìm hiểu mô hình phổ biến hơn và ít đau đầu hơn là dùng đó là multiple process (master và workers)

Chính xác là lập trình đa luồn rất khó, và nhửng người lập trình cái này mà chạy ko bị deadlock tôi biết đều xuất thân là system ra hoặc từ lập trình viên mà làm luôn cả system, am hiểu cả 2 mới có thể code được. Và điểm chung mấy ông này (ở VN) là mấy ông già . Tôi nghi là mấy ông già này có chục năm nữa vẫn sẽ code tốt, còn cách tiếp cận lập trình như người trẽ hiện tại toàn chạy theo cái xu hướng, cái dễ xài không à, trướt mắt là tiết kiệm kha khá thời gian, nhưng cá nhân tôi nghĩ cái gì cũng có tradeoff, xong song với chạy theo xu hướng thì nên đào sâu vào nhưng cái cốt lõi thi đảm bảo già vẫn sống khỏe với nghề, ko phải ai cũng có thể làm project manager như mấy ông dev hay tâm sự lúc về già, nên tôi nghi tới tầm 3x, 4x có khi sẽ nói là tuổi nghề lập trình ngắn nếu cứ chạy theo mấy cái ngôn ngữ xu hướng

Last edited: Sep 5, 2020

XinClipBiBan

Đây có phải bài trắc nghiệm các câu hỏi mẩu giáo không.

via theNEXTvoz for iPhone

Vâng là mẫu giáo, xem thử anh có thông minh hơn các cháu ở trường mầm non không

Tại sao nodejs là single thread

tan2cang

Em hay nghe team nói là để mấy con worker xử lý. Vậy mấy con worker là gì zợ?

Sent from Xiaomi Redmi 7 using vozFApp

prescolt

Vâng là mẫu giáo, xem thử anh có thông minh hơn các cháu ở trường mầm non không

Tại sao nodejs là single thread

bạn này nói chuyện giống mấy thằng nhóc quá, tôi coi như cục đá vô giá trị, ko cần care từ post này

haSei

Tôi ko biết ngôn ngữ ngoài c hay java ra khi xủ li mutex cost bao lâu, với c chỉ tầm 2x ns là trên các cpu gọi là củ như x5600 . Trên cpu đời mới có khi còn thấp hơn. Và theo như hệ thống hiện tai tôi thấy hiêu năng còn rất nhiều, nếu ko dùng ipc shm chi dung
Thread mem thì redis sẽ phải chạy nhiều hơn, redis độ trễ tâm 1ms vẫn cao nếu gọi liên tục. Và dù cho có chạy môt thread riêng đẻ làm việc trên thì vơi c củng phải dùng shm và ipc. Vậy mấy ngon ngữ cấp cao hơn cho phép thread nói chuyện với nhau mà ko có ipc shm à ?

via theNEXTvoz for iPhone

Không, theo mình biết là không có, vì đó là nguyên lý ở tầng system. Không thay đổi được. Nhưng ngôn ngữ lập trình, nó ở tầng abstract hơn, có những quy tắc về cách user có thể sử dụng share memory. Ví dụ, có ngôn ngữ có thể cho phép user không cần tự tạo shm để giao tiếp giữa các thread, mà đẩy việc này cho feature built-in của ngôn ngữ, ví dụ như Future của Java, Channel của Golang... Có những ngôn ngữ, như erlang, còn không cung cấp khả năng tự tạo ra shm khi thực thi concurrency.
Đó là cách thiết kế của ngôn ngữ.

haSei

Chính xác là lập trình đa luồn rất khó, và nhửng người lập trình cái này mà chạy ko bị deadlock tôi biết đều xuất thân là system ra hoặc từ lập trình viên mà làm luôn cả system, am hiểu cả 2 mới có thể code được. Và điểm chung mấy ông này (ở VN) là mấy ông già . Tôi nghi là mấy ông già này có chục năm nữa vẫn sẽ code tốt, còn cách tiếp cận lập trình như người trẽ hiện tại toàn chạy theo cái xu hướng, cái dễ xài không à, trướt mắt là tiết kiệm kha khá thời gian, nhưng cá nhân tôi nghĩ cái gì cũng có tradeoff, xong song với chạy theo xu hướng thì nên đào sâu vào nhưng cái cốt lõi thi đảm bảo già vẫn sống khỏe với nghề, ko phải ai cũng có thể làm project manager như mấy ông dev hay tâm sự lúc về già, nên tôi nghi tới tầm 3x, 4x có khi sẽ nói là tuổi nghề lập trình ngắn nếu cứ chạy theo mấy cái ngôn ngữ xu hướng

Em đồng ý với bác điểm này, hơi thiên kiến nhưng theo em những người từ dev theo hệ quản lý là đã bỏ nghề. Em cũng không tin thuyết dev là nghề có tuổi thọ ngắn, đầy ông dev em biết, không phải ở Việt Nam, toàn 50 60 tuổi. Nhưng em nghĩ bác đánh giá thấp giới trẻ quá đấy. Hơn nữa, dù ít dù nhiều, cách bác chia sẻ kiến thức như những post vừa rồi cũng giúp, biết đâu được, một bạn trẻ kiểu giống bác nói thay đổi mindset và tìm cách phát triển bản thân hơn. Tóm lại, hơi dở hơi nhưng em cảm thấy đóng góp cho cộng đồng vẫn tốt hơn đánh giá và phán xét, bác nhỉ. Vì đánh giá, và phán xét, là việc hoàn toàn vô ích.

VietNamVoDichAFF

Dưới góc nhìn của mình, mình thấy nhân sự ngành lập trình phần mềm (những người viết mã nha) có hai loại, mình dùng từ loại không có ý mỉa mai, chê trách gì đâu nha vì có cả mình trong đó mà.
1 là thợ code: Cái này thì ở đâu cũng rất nhiều. Vài ba khóa học, đọc tài liệu là làm được rồi ạ.
2 là Software engineer: thì như bác prescolt chia sẽ, engineer thì họ hiểu cái họ đang làm, từ tầng cao đến tầng dưới đáy rồi đến tầng OS đến cả tầng 10101010101 của phần cứng.
Trong Engineer đích thực, khi đó phân ra các level tùy vào sự hiểu biết đến tầng nào.
Bởi vậy, Senior Android/Golang Engineer nó cách xa Senior Android/Golang Developer.

Kiểu như Một anh biết nối dây đỏ với đỏ, xanh với xanh, vàng với vàng là điện sẽ sáng và làm thuần thục nó. Nếu như môn hóa học cấp 2 mà cho ba lọ hóa chất không nhãn là gãy cánh ngay.

Còn 1 anh thì có thể định nghĩa ra dây xanh, dây vàng, dây đỏ để thuận tiện lắp. Mất màu thì biết cách tìm ra dây nóng, dây lạnh để nối.

Last edited: Sep 6, 2020

voiconoi

Single hay multi nó tùy thuộc vào runtime-environment chứ chả liên quan gì đến ngôn ngữ, vì vậy nên câu hỏi của chủ thớt trên là sai. Trên trình duyệt thì chỉ cho phép single thread nhưng nodejs phía server có thể chạy multi thread ngon lành.
Còn vụ ông anh trên công ty cũng sai, main thread và worker thread ko dính gì đến nhau cả. Phải nhờ thằng trình duyệt là thằng trung gian cho các thread này giao tiếp với nhau

Tại sao nodejs là single thread

Nói sai nữa bác. Trình duyệt khi bác gửi request thì sao, ko lẽ trong lúc gửi bác ko làm đc việc gì nữa(dân gian gọi là lắc đó

Tại sao nodejs là single thread
Tại sao nodejs là single thread
). Trên trình duyệt nó cung cấp 1 đống APIs hoạt động độc lập với runtime của js. Và trên nodeJs thì là các APIs C++. Đúng là js chỉ chạy single trên runtime, nhưng nó có các Apis ngoài runtime cung cấp khả năng xử lý bất đồng bộ. Multi thread là các Apis bổ sung

Sent from Samsung SM-N950F using vozFApp

XinClipBiBan

Nói sai nữa bác. Trình duyệt khi bác gửi request thì sao, ko lẽ trong lúc gửi bác ko làm đc việc gì nữa(dân gian gọi là lắc đó

Tại sao nodejs là single thread
Tại sao nodejs là single thread
). Trên trình duyệt nó cung cấp 1 đống APIs hoạt động độc lập với runtime của js. Và trên nodeJs thì là các APIs C++. Đúng là js chỉ chạy single trên runtime, nhưng nó có các Apis ngoài runtime cung cấp khả năng xử lý bất đồng bộ. Multi thread là các Apis bổ sung

Sent from Samsung SM-N950F using vozFApp

Single thread theo hướng event-driven nó vậy đó fence, các hoạt động i/o như gọi API thì js nó không tự tạo thread để xử lý mà bắn cho thằng khác(trình duyệt) lo còn bản thân js nó ngồi chơi xơi nước đợi kết quả không à.
Ngược lại nếu gọi 1 hàm đệ quy tính toán nặng trong main thread(js tự thân vận động) thì web nó treo đến khi hàm đó chạy xong thì thôi. Đấy mới chính là cái khẳng định js trên browser đơn thuần là single thread.

Tại sao nodejs là single thread

Còn việc có thể tạo lập các service worker thì nó là runtime của browser, browser có hỗ trợ thì dùng, không thì thôi nên không thể nói nó là của js đc.

haSei

Single thread theo hướng event-driven nó vậy đó fence, các hoạt động i/o như gọi API thì js nó không tự tạo thread để xử lý mà bắn cho thằng khác(trình duyệt) lo còn bản thân js nó ngồi chơi xơi nước đợi kết quả không à.
Ngược lại nếu gọi 1 hàm đệ quy tính toán nặng trong main thread(js tự thân vận động) thì web nó treo đến khi hàm đó chạy xong thì thôi. Đấy mới chính là cái khẳng định js trên browser đơn thuần là single thread.

Tại sao nodejs là single thread

Còn việc có thể tạo lập các service worker thì nó là runtime của browser, browser có hỗ trợ thì dùng, không thì thôi nên không thể nói nó là của js đc.

Theo bác runtime environment của Java hoặc C là gì, và điểm gì của runtime environment quyết định tính multi-thread của ứng dụng viết bằng java hoặc C.

Last edited: Sep 6, 2020

soihoang

runtime cũng chỉ là một phần trong việc giải quyết vấn đề thôi. VD jvm nó ko có actor model thì thằng akka nó cũng "mô phỏng lại", .net nó có orlearn hay jvm ko có "lightweight thread" fiber/corotine thì clojure nó tự implement một cái, hay kotlin nó cũng tự làm.

Khi nào như thế thì chắc ko bằng được runtime support rồi, và khi họ thấy cần thì "theo một cách nào đó" nó cũng implenent cơ chế đó một cách native như project loom của jvm. Hay clojure nó không làm làm được tail call optimization thì cũng bó tay.

Quay lại câu hỏi của bác thì với jvm nó có sẵn tạo thread, quản lý thread và đồng bộ dữ liệu giữa thread các thì nó là thread based runtime rồi

Tại sao nodejs là single thread

Ikeda

singlethread hay multithread thì nhìn spec của nn là biết, js ko có đặc tả multithread trong spec nên đám browsers, nodejs mỗi thằng implement một kiểu (worker, cluster,...) tuy ko tận dụng đc hết sức mạnh cpu như c, java nhưng cũng có thể coi là multithread

r0ut1n3

Về giải thích thì mình tin chắc là có nhiều bác trên này sẽ giải thích hay hơn mình, nhưng nói Node.js là single thread thì sai

haSei

Về giải thích thì mình tin chắc là có nhiều bác trên này sẽ giải thích hay hơn mình, nhưng nói Node.js là single thread thì sai

Vì sao bác nhỉ

quandaso

Về giải thích thì mình tin chắc là có nhiều bác trên này sẽ giải thích hay hơn mình, nhưng nói Node.js là single thread thì sai

ý bạn là runtime có mấy cái background thread chạy phía dưới bắn result lại cho thread chính? . . Giống như tôi code java trên 1 main thread thôi, còn cái jvm nó đẻ ra vài chục cái thread khác xử lí x,y,z gì đó nhưng vẫn coi là mình đang code multithread?

Tại sao nodejs là single thread
Thế chắc chả có ngôn ngữ nào là single thread đúng nghĩa đâu

vinhomn

mà nodejs đâu phải language , nó là runtime environment cơ nhỉ?
theo mình hiểu thì về mặt language chính js ko define bất kỳ feature nào cho việc support multi thread nên nó chỉ single thread
Còn các external solution/framework đc tạo ra để support thread management thì nó đâu có phụ thuộc vào language đâu, đưa ra mấy cái luận điểm kiểu vậy thấy không chính xác
Thấy có nhiều người cũng hay nhầm lẫn, VD với setTimeout function nó đâu phải là language feature

Gia Cát Lợn

Cho em hỏi ngu cái, nếu thằng event loop nó trả về đúng lúc bên stack đang nhét 1 lệnh thực thi luôn thì sao nhỉ? 2 thằng cùng dc nhét vào cùng lúc thì sao nó biết nhét thằng nào vào trước

vinhomn

Cho em hỏi ngu cái, nếu thằng event loop nó trả về đúng lúc bên stack đang nhét 1 lệnh thực thi luôn thì sao nhỉ? 2 thằng cùng dc nhét vào cùng lúc thì sao nó biết nhét thằng nào vào trước

Chiểu theo cái video giải thích của Philip Roberts, và theo cách mà 1 js program được load nhé, thì mình thấy ko thể có trường hợp như bạn mô tả xảy ra.
Khi 1 js program được load, trong cái execution context đó thì hàm main (entry point of the program) được load thẳng vào call stack, cùng với đó là tất cả các hàm được gọi đến trong main. Tất cả đống này trong stack là đống data duy nhất được load trực tiếp vào stack mà ko thông qua event loop.
Sau đó mọi data khác muốn được đẩy vào stack đều phải đi qua event loop.
Đó cũng là điều giải thích cho trường hợp tạo ra 1 cái js loop gọi vô hạn đến 1 hàm, làm treo đơ luôn browser
VD với cái program này:

JavaScript:

function foo() {
    return foo();
}
foo();

hàm foo được gọi đến liên tục, call stack cứ thế đầy lên mà ko pop đc cái data nào ra cả, dẫn tới ko có bất cứ data nào trong event loop đc push vào stack cả (khi stack chưa thỏa mãn điều kiện empty) làm treo luôn browser hoặc xuất hiện lỗi "RangeError: Maximum call stack size exceeded"

Hoai cmn Linh

Cho em hỏi ngu cái, nếu thằng event loop nó trả về đúng lúc bên stack đang nhét 1 lệnh thực thi luôn thì sao nhỉ? 2 thằng cùng dc nhét vào cùng lúc thì sao nó biết nhét thằng nào vào trước

Chiểu theo cái video giải thích của Philip Roberts, và theo cách mà 1 js program được load nhé, thì mình thấy ko thể có trường hợp như bạn mô tả xảy ra.
Khi 1 js program được load, trong cái execution context đó thì hàm main (entry point of the program) được load thẳng vào call stack, cùng với đó là tất cả các hàm được gọi đến trong main. Tất cả đống này trong stack là đống data duy nhất được load trực tiếp vào stack mà ko thông qua event loop.
Sau đó mọi data khác muốn được đẩy vào stack đều phải đi qua event loop.
Đó cũng là điều giải thích cho trường hợp tạo ra 1 cái js loop gọi vô hạn đến 1 hàm, làm treo đơ luôn browser
VD với cái program này:

JavaScript:

function foo() {
    return foo();
}
foo();

hàm foo được gọi đến liên tục, call stack cứ thế đầy lên mà ko pop đc cái data nào ra cả, dẫn tới ko có bất cứ data nào trong event loop đc push vào stack cả (khi stack chưa thỏa mãn điều kiện empty) làm treo luôn browser hoặc xuất hiện lỗi "RangeError: Maximum call stack size exceeded"

Ko hẳn, mình nhớ đợt trước có xem cái video xong đào sâu mấy blog về cái này thì khi nào trong call stack đc clear hết thì mới push tiếp cái event loop đã đc resolve vào stack để thực thi
Ví dụ hàm set time out 3s sau đúng 3 giây nó resolved nhưng đúng lúc đó trong stack còn lệnh thì vẫn thực thi hết cái lệnh đó rồi mới làm tiếp cái set time out kia. Thời gian sẽ chậm hơn 3s

Gia Cát Lợn

À em quên mất, mấy thằng chạy luôn nó trên thằng Main, chạy hết đống trong main rồi nó mới vứt thằng main ra->empty-> chạy event loop
Thanks 2 bác

Tại sao nodejs là single thread

kenptit

JS là single thread, non-blocking IO

voiconoi

Tại sao nodejs là single thread

Bác cho em hỏi tí

Sent from Samsung SM-N950F using vozFApp