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
Bạn trên nhạy cảm quá, thấy có ai chửi bới gì trong này đâu. Mỳ ăn liền thì nói mì ăn liền, có ai nói là ko được xài mì ăn liền đâu.
Right tool for right job. Có gì phải lăn tăn nhỉ.
 
Mình chẳng có gì để mà tư ti cả, kinh nghiệm của bạn không phải là kinh nghiệm của người khác. Câu post trên nếu quan tâm thì tự đi tìm hiểu tại sao như vậy, trong sự nghiệp nhiều lúc người ta chỉ cần một gợi ý nhỏ thôi là nhảy vọt. Phần còn lại là bản thân nghĩ sao về nó, có tìm hiểu hay không hay lại nói thế này thế kia, vô thưởng vô phạt blabal, không có đóng góp vâng vâng...tại bạn làm biếng thôi.
Trong thread này có người đã viết, ngôn ngữ ko có mutex là ko phải đa luồn tôi bổ sung thêm ko có shared memory. Còn đi vô hàm gọi mà phán xét ko có đa luồng, thì theo kinh nghiệm của tôi đây là kiểu lập trình viên suốt ngày đi lên github search cái này cái kia về xài kiểu mấy ông thợ gõ thôi
Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.
 
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?
 
Bạn trên nhạy cảm quá, thấy có ai chửi bới gì trong này đâu. Mỳ ăn liền thì nói mì ăn liền, có ai nói là ko được xài mì ăn liền đâu.
Right tool for right job. Có gì phải lăn tăn nhỉ.
A nói vụ mì ăn liên tôi mới nhớ nhân tiện nói thêm 1 vài vấn đề trong box này thôi. Mây anh dev già khó tính xem language cũng chia thượng đẳng lắm. Bên nodejs thread a có cmt gì thì bữa trước tôi vẫn thấy thôi.
Còn language thì chỉ có 2 loai thôi. Loại có người xài và ko ai xài.
 
Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.
Bạn viết mutithread mà ko xài shared memory thì tôi đặt vấn đề đơn giản như một cái ứng dụng firewall chạy đa luồn có khai bao một pool whitelist ip, ko share cho nhau vậy 32 cái thread khởi tạo 32 cái danh sách IP pool này có phải là sự tiêu tốn tài nguyên không ? rồi khi update 1 cái ip vào pool thì 32 cái thread thi nhau update, ok fine nếu chạy nhẹ nhàng ko vấn đề gì, nhưng thử nghĩ xem với một ứng dụng concurrent tầm 1tr req 1 lúc thì. Ko cần shared memory chạy muti thread thì khác gì muti process ? cứ fork ra rồi chạy, viết thread làm gì cho khổ dâm.
- Block với non blocking là cách hệ thống các thao tác trong code, bản thân ngôn ngữ làm éo gì có khái niệm ngôn ngữ blocking với nonblocking. Đây chỉ là thuật ngữ mấy thằng cuổng nodejs đưa ra, nào là nodejs no blocking balabla, bản chất vấn đề ko phải ở ngôn ngữ mà là nó thiết kế dể chay non blocking đơn giản để deploy, ko phức tạp như C hay java. Và bây giờ người ta nâng tầm thương hiệu node js là ngôn ngữ non blocking :haha:, rồi xếp mấy thằng C vói java vào blocking, trong khi bản chất vấn đề là code ngu C với java nên ko làm duoc non blocking nên có thằng tạo ra cái nodejs cho các dev nữa mùa or nhu cầu đơn giản nhanh gọn vô xài thôi. Tôi ko chê ai xài nodeJS nhé, ko lại bảo tôi kinh bỉ
 
Sửa lần cuố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?
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 à
 
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".
 
Mutithread còn đặt biệt sử dung trong ứng dụng ví dụ game, ko xài share memory (shm), mỗi thread lưu một thông tin role của user, rồi game 10 cái thread vậy 1 thread chỉ duoc xử lí 1 rolename thôi à, vậy xài mutithead ko có SHM làm éo gì nữa. Trong khi có shm, thead nào cũng ko quan trong cứ móc lên rồi thao tác xong ghi xuống shm, dinh ky luu vào DB. Tôi vẫn chưa hiểu người ta viết mutithread ko dùng shm cho ngữ cãnh nào
Mà đã có SHM thì phải có mutex, ko có mutex lại dead lock. Nên tôi nói 2 thằng này là đặc tính mà một ngôn ngữ support đa luồn mạnh hay không. Còn thể loại chạy mutithread ko dùng mấy cái này ko biết là thể loại gì, ngữ cãnh nào, nếu tôi ko biết thi có thể chỉ ra, chẳng có vấn đề gì cả
 
Sửa lần cuối:
Đúng rồi, đưa ra dẫn chứng, lập luận, thì mọi người còn hiểu mà tranh luận với bác chứ.
Mutex và shared memory không phải là biểu hiện của một multiple thread language. Bác biết có nhiều ngôn ngữ không cần share memory để là multithread language, đúng không ?
Vì sao, vì mutex là mutual exclusion, là biểu hiện của blocking language, phân biệt với non-blocking language, là một phương pháp được dùng khi giải quyết những issue của Concurrency-Implement-Kiểu-Shared-Memory.
Và có những cách khác để implement Concurrency: Event Driven, Message Driven, Immutable... Bác biết, đúng không? Một Multiple Thread Language với architect không hỗ trợ Concurrency-Implement-Kiểu-Shared-Memory, mà hỗ trợ những kiểu concurrecy khác, thì không cần mutex và shared memory.
Multiple Thread Language, ý nghĩa nó nằm trong tên của nó thôi. Là ngôn ngữ lập trình có hỗ trợ tạo Thread, mà không thông qua thread party.
mình nghĩ bạn nên đọc bài này trước: https://crystal-lang.org/reference/guides/concurrency.html
 
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)
 
Bạn viết mutithread mà ko xài shared memory thì tôi đặt vấn đề đơn giản như một cái ứng dụng firewall chạy đa luồn có khai bao một pool whitelist ip, ko share cho nhau vậy 32 cái thread khởi tạo 32 cái danh sách IP pool này có phải là sự tiêu tốn tài nguyên không ? rồi khi update 1 cái ip vào pool thì 32 cái thread thi nhau update, ok fine nếu chạy nhẹ nhàng ko vấn đề gì, nhưng thử nghĩ xem với một ứng dụng concurrent tầm 1tr req 1 lúc thì. Ko cần shared memory chạy muti thread thì khác gì muti process ? cứ fork ra rồi chạy, viết thread làm gì cho khổ dâm.
- Block với non blocking là cách hệ thống các thao tác trong code, bản thân ngôn ngữ làm éo gì có khái niệm ngôn ngữ blocking với nonblocking. Đây chỉ là thuật ngữ mấy thằng cuổng nodejs đưa ra, nào là nodejs no blocking balabla, bản chất vấn đề ko phải ở ngôn ngữ mà là nó thiết kế dể chay non blocking đơn giản để deploy, ko phức tạp như C hay java. Và bây giờ người ta nâng tầm thương hiệu node js là ngôn ngữ non blocking :haha:, rồi xếp mấy thằng C vói java vào blocking, trong khi bản chất vấnđề là code ngu C với java nên ko làm duoc non blocking thôi.
Hở, bác phân biệt như nào là multi thread như nào là multi process vậy.
Trở lại bài toán của bác, Bác chạy 32 thread để crawl white IP, ý bác là phải tồn tài một shared variable để store và update IP một cách atomic, mình cho là bác sử dụng ReadWriteLock block đoạn update IP đi. Kiểu gì Core của bác cũng bị block, đúng hem? Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?
Mà chắc là mình hiểu sai cách bác giải bài toán nhỉ, chứ ai lại có cách làm kỳ cục thế?
Và thật ra bài toán của bác rất kinh điển, mình đang nói về cách handle dễ nhất để không phải shared memory.
 
Hở, bác phân biệt như nào là multi thread như nào là multi process vậy.
Trở lại bài toán của bác, Bác chạy 32 thread để crawl white IP, ý bác là phải tồn tài một shared variable để store và update IP một cách atomic, mình cho là bác sử dụng ReadWriteLock block đoạn update IP đi. Kiểu gì Core của bác cũng bị block, đúng hem? Mình có một cách khác đây, mình dùng một thread quản lý thông tin Ips, mình dùng 4 thread để chạy tác vụ, mỗi khi cần thông tin IP, sẽ call request tới thread này để get và set thông tin Ips. Trong thời gian chờ đợi kết quả, mình release core để thực hiện các tác vụ khác. Cách của mình giảm được context switch, đúng không?
Mà chắc là mình hiểu sai cách bác giải bài toán nhỉ, chứ ai lại có cách làm kỳ cục thế?
Và thật ra bài toán của bác rất kinh điển, mình đang nói về cách handle dễ nhất để không phải shared memory.
Đây là một chương trình tường lửa, có 32 thread, 32 thread mỗi thread pin xuống một queue NIC interface
32 thread này xử lí packet viec so sánh đia chỉ IP là việc thực hiện liên tục, ko phải là việc lâu lâu làm một lần và xử lí gói tin tới hàng triệu thì không có khái niệm chờ đi làm cái khác, 32 thread này lấy danh sách ip whitelist từ shm share chung, danh sách này được update từ thao tác cua user vào redis, và 1 trong 32 thread này cái nào cũng có thể tự nó update dinh kỳ được toàn bộ từ redis vào shm miễn sao request đi vào có destination tương ứng với whitelist IP pool và expire time của list đã quá ngưỡng define trong thread . Dead lock kiểu gì nếu khi update đã có mutex khóa cái shm lại ?
Bạn tách ra một thread để làm việc đó rồi đi làm việc khác vậy thì cái firewall vứt đi rồi. Nếu bạn ko làm việc khí thi bạn đang yêu cầu 32 thread đi lúc nào cũng phải gọi vào 1 thread duy nhất để liên tục trích xuất whitelist pool à ?
 
Sửa lần cuối:
Đây là một chương trình tường lửa, có 32 thread, 32 thread mỗi thread pin xuống một queue NIC interface
32 thread này xử lí packet viec so sánh đia chỉ IP là việc thực hiện liên tục, ko phải là việc lâu lâu làm một lần và xử lí gói tin tới hàng triệu thì không có khái niệm chờ đi làm cái khác, 32 thread này lấy danh sách ip whitelist từ shm share chung, danh sách này được update từ thao tác cua user vào redis, và 1 trong 32 thread này cái nào cũng có thể update dinh kỳ được toàn bộ từ redis vào shm miễn sao request đi vào có destination tương ứng với destination IP đang chạy và expire time của list đã quá ngưỡng define trong thread .
Bạn tách ra một thread để làm việc đó rồi đi làm việc khác vậy thì cái firewall vứt đi rồi
Ủa share memory ở đâu vậy bác ? Cái nào là share memory bác?
 
// ô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?
 
// ô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ả
 
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?
 
Chỗ nào networking, đơn gian ví dụ chương trình firewall mutithread thôi cho dễ hình dung, cấp hệ điều hành, chẵng có networking nào cả
Mình call tới thread stỏage, release thread để core phục vụ thread khác, sau đó thread storage sẽ notify lại mình để xử lý tiếp.
Mình quote nhầm bác @Nipin
 
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 :rolleyes:
 
Sửa lần cuối:

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.135
Quay lại
Lên đầu trang