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

  • Người tạo chủ đề Người tạo chủ đề teeeeeeeee
  • Ngày bắt đầu Ngày bắt đầu
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.
 
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.
 
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.
 
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 :">
 
Sửa lần cuối:
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 :D. Nếu có 2 người dùng đăng nhập lần lượt đồng thời :D (liền nhau, cách nhau không đáng kể), người đăng nhập thứ 2 sẽ phải đợi bao lâu để có thể đăng nhập?", sau đó sẽ có vài câu tại sao nữa, nên bạn nào lanh lợi thì nên giải thích luôn (nếu bạn chắc chắn đoán được câu hỏi tiếp theo). Phiên phiến thôi, chính xác tới từng "phút" là được rồi.
Bác Zuru nói đúng á bác. Nếu người ta hỏi vặn thì đề này thiếu dữ kiện thật sự. Bác đang mặc định cách implement chuẩn của NodeJS và spring boot, trong happy case. Đúng là mấy câu này chỉ nên hỏi cho trên fresher một chút.
 
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.
 
Đú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.
 
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.
 
Nhưng nó không xoá memory cache trong quá trình context switch bác à, nó flush cache trong quá trình thực thi process. Ngoài ra, L1 không được tag bằng virtual memory, L1 là real memory tag, chỉ có index là virtual ( nói nôm na thì memory cache được chia thành nhiều set, mỗi set chứa nhiều line, index là tìm set, tag tìm line). Nói tóm lại, flush cache là do core quyết định, không phải do context switch.

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

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

Sent from Xiaomi Redmi 5A using vozFApp
Thank bác, đúng là như bác nói.
 
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 :doubt: 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 :doubt: mà ông kia thì đang mentor cho em nên không dám cãi :sweat:
Theo các fen thì có ý kiến thế nào ?
Single thread nhưng lại là multiple process
 
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 á. :LOL:.
 
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.
 
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
 
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ỉ?
 
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é.
 

Thống kê chủ đề

Ngày tạo
teeeeeeeee,
Người trả lời cuối
AnyaKyle,
Trả lời
199
Lượt xem
30.117
Quay lại
Lên đầu trang