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 Nipin
thằng nào bảo js là multithread thì cứ vả vào mồm. 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. 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
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ư 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ư 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
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. teeeeeeeee Dễ mà ta. Dùng cái setTimeOut là là đã sử dụng webAPI r mai fen via
theNEXTvoz for iPhone zulu Dùng cái setTimeOut là là đã sử dụng webAPI r mai fen 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 via theNEXTvoz for iPhone hình như click event nó cũng là webapi 22mario9x 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ỉ
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ỉ
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. 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
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ờ )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. 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ờ luồng em đang nói là luồng của node, còn luồng về cpu là khác bác ơi 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. 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 TrangTraiCoDon Js vẫn là single thread, 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. 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
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 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. 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. cache nó mang nhiều nghĩa lắm bạn ơi :v 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. cache nó mang nhiều nghĩa lắm bạn ơi :v 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
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. 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. 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. Có 2 loại coroutine, stackful và stackless. 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. 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
Pianist Có 2 loại coroutine, stackful và stackless. 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. 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.
À 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. 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. 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? 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
rauma01 quăng đáp án xem nào, bí bí hiểm hiểm 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 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
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. Sent from Xiaomi Redmi 5A using vozFApp haSei
Vụ này tùy nhé bác, như mình đã nói. 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 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.
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 á. .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 ... 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 ạ
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
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
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? 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ả
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.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ả 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 đ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. 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. 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ả
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.Networking Last edited: Sep 3, 2020 HutCanPheLam Networking Sư phụ ơi em đang đi theo con đường của sư phụ
này. Sư phụ chỉ đường e với nntgwww Networking 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.
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? 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 Nên mình mới nói bác là người thích tỏ ra thượng đẳng. Networking 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? 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? 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. nguyenna Vừa đọc 1 bài JS, theo mình hiểu ngắn gọn (liên quan tới topic prescolt Vừa đọc 1 bài JS, theo mình hiểu ngắn gọn (liên quan tới topic 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
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 . 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) 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. 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. Đú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ứ. 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. 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. 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ứ. 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. 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 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ứ. 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. Hở, bác phân biệt như nào là multi thread như nào là multi process vậy. prescolt Hở, bác phân biệt như nào là multi thread như nào là multi process vậy. Đâ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 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 Ủ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. 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
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 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: 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. 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 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. 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: 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. 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... 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... 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... 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: 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... 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. prescolt Bác ơi, không đâu. Nó là kiểu event driven kinh điển thôi. đã 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ả. 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 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. 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. nntgwww Chắc anh Nip ignore tôi rồi nên quote cung ko dc g
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 )).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. Ừ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. 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. 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. 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. 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. 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. 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 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 Ồ, 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. 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. 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. 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. 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 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
prescolt
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
Đâ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. 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. 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. 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
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. 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 via theNEXTvoz for iPhone zulu Tôi thiết kế kiểu dữ liệu như sau 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ó 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 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. 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ó
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. 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 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. 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. 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 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 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 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. 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à. 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. 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ổ sungSent 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 đó
). 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 à. 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 à. 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 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? vinhomn mà nodejs đâu phải language , nó là runtime environment cơ nhỉ? 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. JavaScript: 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. JavaScript: 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 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 kenptit JS là single thread, non-blocking IO voiconoi Bác cho em hỏi tí Sent from Samsung SM-N950F using vozFApp |