thảo luận Javascript có thực sự là single thread

teeeeeeeee said:

Hi mấy thím,
Chả là trên công ty em có ông anh cho rằng JS không phải là single thread bởi vì có các thread khác như là webworker,..
Nhưng theo em hiểu thì các 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 mà ông kia thì đang mentor cho em nên không dám cãi
Theo các fen thì có ý kiến thế nào ?

zizz said:

js single thread mà thím

teeeeeeeee said:

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

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

teeeeeeeee said:

Hi mấy thím,
Chả là trên công ty em có ông anh cho rằng JS không phải là single thread bởi vì có các thread khác như là webworker,..
Nhưng theo em hiểu thì các 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 mà ông kia thì đang mentor cho em nên không dám cãi
Theo các fen thì có ý kiến thế nào ?

rauma01 said:

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.

BaronNashor said:

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ồ

rauma01 said:

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.

zulu said:

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

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

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

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

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.

kazimhung559 said:

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ỉ

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

zizz said:

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 )

rauma01 said:

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

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

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ờ )

zulu said:

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

Nipin said:

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

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.

voiconoi said:

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

22mario9x said:

kevin.leptons said:

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.

cugiametruyen85 said:

Đó là lý thuyết thôi, còn thực tế thì spec và impl của lang đôi khi đi liền với nhau quan trọng là cái spec đó nó rộng đến đâu.
Ví dụ nhé:
https://docs.oracle.com/javase/specs/jls/se14/html/jls-17.html
https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency:_goroutines_and_channels
https://erlang.org/doc/reference_manual/processes.html

Nipin said:

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.

zhukov said:

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

zzchaolegionzz said:

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:

zhukov said:

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

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

rauma01 said:

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 . Nếu có 2 người dùng đăng nhập lần lượt đồng thời (liền nhau, cách nhau không đáng kể), người đăng nhập thứ 2 sẽ phải đợi bao lâu để có thể đăng nhập?", sau đó sẽ có vài câu tại sao nữa, nên bạn nào lanh lợi thì nên giải thích luôn (nếu bạn chắc chắn đoán được câu hỏi tiếp theo). Phiên phiến thôi, chính xác tới từng "phút" là được rồi.

bribnt said:

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.

zhukov said:

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

zhukov said:

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

bribnt said:

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/

bribnt said:

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.

bribnt said:

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

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

soihoang said:

đâ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.

rauma01 said:

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.

soihoang said:

đâ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.

rauma01 said:

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.

meohen2109 said:

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

Nipin said:

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

bribnt said:

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.

bribnt said:

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.

rauma01 said:

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 . Nếu có 2 người dùng đăng nhập lần lượt đồng thời (liền nhau, cách nhau không đáng kể), người đăng nhập thứ 2 sẽ phải đợi bao lâu để có thể đăng nhập?", sau đó sẽ có vài câu tại sao nữa, nên bạn nào lanh lợi thì nên giải thích luôn (nếu bạn chắc chắn đoán được câu hỏi tiếp theo). Phiên phiến thôi, chính xác tới từng "phút" là được rồi.

Nipin said:

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

haSei said:

Đú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 said:

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.

rauma01 said:

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

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.

bribnt said:

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

teeeeeeeee said:

Hi mấy thím,
Chả là trên công ty em có ông anh cho rằng JS không phải là single thread bởi vì có các thread khác như là webworker,..
Nhưng theo em hiểu thì các 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 mà ông kia thì đang mentor cho em nên không dám cãi
Theo các fen thì có ý kiến thế nào ?

kyo_pyro said:

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

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.

rauma01 said:

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.

zulu said:

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

zulu said:

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

prescolt said:

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

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

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

rauma01 said:

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

meohen2109 said:

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

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.

ldarj3 said:

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 ạ

prescolt said:

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

prescolt said:

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

ldarj3 said:

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 ạ

nntgwww said:

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

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

rauma01 said:

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

rauma01 said:

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

nntgwww said:

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

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 . Trong khi nhiều dev cũng ko đồng ý phân biệt khinh bỉ help desk, network.

prescolt said:

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ì

prescolt said:

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ì

haSei said:

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.

HutCanPheLam said:

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

prescolt said:

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ì

prescolt said:

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ì

haSei said:

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.

nguyenna said:

Vừa đọc 1 bài JS, theo mình hiểu ngắn gọn (liên quan tới topic )
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.

ldarj3 said:

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 ạ

prescolt said:

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

prescolt said:

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

prescolt said:

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

Đú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 said:

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?

haSei said:

Đú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 said:

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.

prescolt said:

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

haSei said:

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

Đâ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

haSei said:

Ủa share memory ở đâu vậy bác ? Cái nào là share memory bá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?

Nipin said:

// ô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?

prescolt said:

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

prescolt said:

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ả

prescolt said:

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ả

Nipin said:

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

haSei said:

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.

haSei said:

À, 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?

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)

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.

Nipin said:

ý 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 said:

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

haSei said:

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

haSei said:

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

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?

Nipin said:

ý 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).

zulu said:

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

haSei said:

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

prescolt said:

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.

haSei said:

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.

Nipin said:

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.

prescolt said:

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 à ?

prescolt said:

đã 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ự ?

Nipin said:

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

haSei said:

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.

zulu said:

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

haSei said:

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

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

Nipin said:

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.

prescolt said:

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

haSei said:

Ừ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ỉ.

prescolt said:

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

haSei said:

Ồ, 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 said:

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

prescolt said:

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.

prescolt said:

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

prescolt said:

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

• 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?

XinClipBiBan said:

• 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

haSei said:

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.

prescolt said:

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

haSei said:

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.

zulu said:

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

haSei said:

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

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

zulu said:

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

zulu said:

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

prescolt said:

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

prescolt said:

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ó

via theNEXTvoz for iPhone

haSei said:

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.

quandaso said:

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)

prescolt said:

Đâ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

XinClipBiBan said:

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

prescolt said:

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

prescolt said:

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

XinClipBiBan said:

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

voiconoi said:

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 đó ). 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 said:

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

r0ut1n3 said:

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

r0ut1n3 said:

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

Gia Cát Lợn said:

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

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

Gia Cát Lợn said:

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

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"

voiconoi said:

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

22mario9x said: