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

[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.
Nên người ta mới nghĩ ra những phương pháp giảm bớt sự phụ thuộc.
Bác đừng định kiến nhé, môt giải pháp chạy tốt cho một ứng dụng 5tr user chưa chắc dùng được cho ứng dụng khác. Ngay từ đầu mình đã nói concurrency share memory là một trong những cách thực thi concurrency mà. Mình không phủ nhận nó. Nhưng vẫn còn những giải pháp khác. Nên mong bác đừng đưa ra một thực tiễn để loại bỏ hoàn toàn lý thuyết.

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

via theNEXTvoz for iPhone

 

[quandaso]

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

 

[jvinhit]

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

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

 

[prescolt]

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

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

 

[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
Thread mem thì redis sẽ phải chạy nhiều hơn, redis độ trễ tâm 1ms vẫn cao nếu gọi liên tục. Và dù cho có chạy môt thread riêng đẻ làm việc trên thì vơi c củng phải dùng shm và ipc. Vậy mấy ngon ngữ cấp cao hơn cho phép thread nói chuyện với nhau mà ko có ipc shm à ?

via theNEXTvoz for iPhone

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

 

[haSei]

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

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

 

[VietNamVoDichAFF]

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

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

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

 

[voiconoi]

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

Nói sai nữa bác. Trình duyệt khi bác gửi request thì sao, ko lẽ trong lúc gửi bác ko làm đc việc gì nữa(dân gian gọi là lắc đó ). Trên trình duyệt nó cung cấp 1 đống APIs hoạt động độc lập với runtime của js. Và trên nodeJs thì là các APIs C++. Đúng là js chỉ chạy single trên runtime, nhưng nó có các Apis ngoài runtime cung cấp khả năng xử lý bất đồng bộ. Multi thread là các Apis bổ sung

Sent from Samsung SM-N950F using vozFApp

 

[XinClipBiBan]

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 à.
Ngược lại nếu gọi 1 hàm đệ quy tính toán nặng trong main thread(js tự thân vận động) thì web nó treo đến khi hàm đó chạy xong thì thôi. Đấy mới chính là cái khẳng định js trên browser đơn thuần là single thread.
Còn việc có thể tạo lập các service worker thì nó là runtime của browser, browser có hỗ trợ thì dùng, không thì thôi nên không thể nói nó là của js đc.

 

[haSei]

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

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

 

[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? Thế chắc chả có ngôn ngữ nào là single thread đúng nghĩa đâu

 

[vinhomn]

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