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

[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:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

 

[prescolt]

À, 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.
Khi tôi write xuông shm tôi có quá trình lock, flush ,update. Thao tác cái này chỉ tốn vài mico second và 1 thread bất kỳ nào cũng tự làm được . Các thread còn lại vẫn xử lí gói tin bình thường trong khi list này bi flush ( bằng cách đọc danh sách tĩnh từ file lưu vào per thread memory) và nó ko ảnh hưởng tới hiệu năng tổng thể. Vậy nên cho dù shm bi lock hay nil thì tôi vẫn có bộ nhớ riêng của thread để lấy dữ liệu ra đối sánh với gói tin, sẽ có xác xuất dữ liệu trong thread ít hơn dữ liệu bên shm, và gói tin đi lọt, nhưng nó khó xãy ra vì phải chính xác đúng thời điểm và nếu xãy ra cũng không làm ăn gì dược với 1 packet.
nếu tôi không dùng shm mà chỉ có per thread memory thì 32 thread của tôi sẽ luôn luôn trong tình trạng lâu lâu phải flush update lại phần danh sách IP này, việc này không phù hợp yêu cầu tốc độ và tăng xác xuất lọt gói tin trong quá trình flush /update per thread memory. Nếu gọi 1 thread để lấy ra danh sách này thì tăng tải trên 1 thead xử lí cái này, 32 thread đồng nghĩa có 32 yêu cầu. nếu thread này quá tải sẽ có nguy cơ deadlock cả cụm.

 

[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
Meanwhile you subhumans are with crab mentality, "blackpilled" doomer faggots and incels
My eyes are open now
(this doesn't affect the political subreddits and boards on this site, they are awful both at reddit and 4chan, literally horseshoe theory)

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.
Despite what the rest of the internet may spout, 4chan has become pretty forgiving in recent years. General threads have a bunch of links with resources, information and such. If you seriously can't be bothered to go through the data, then you might have a mental disability, and so, deserve to be mocked/ridiculed.

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:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

Vậy thì bạn chưa thực sự bao giờ viết ứng dụng đa luồng, cái bạn mô tả chỉ là một kiểu chia ra nhiều process con chuyên biệt chứ ko phải mục đích chính người ta thiết kế đa luồng.
Khi tôi write xuông shm tôi có quá trình lock, flush ,update. Thao tác cái này chỉ tốn vài mico second và 1 thread bất kỳ nào cũng tự làm được . Các thread còn lại vẫn xử lí gói tin bình thường trong khi list này bi flush ( bằng cách đọc danh sách tĩnh lấy ra từ cái shm lưu vào per thread memory) và nó ko ảnh hưởng tới hiệu năng tổng thể. Vậy nên cho dù shm bi lock hay nil thì tôi vẫn có bộ nhớ riêng của thread để lấy dữ liệu ra đối sánh với gói tin, sẽ có xác xuất dữ liệu trong thread ít hơn dữ liệu bên shm, và gói tin đi lọt, nhưng nó khó xãy ra và nếu xãy ra cũng không làm ăn gì dược

Mình nói rồi ấy, ví dụ 32 threads của bác đồng thời write. Tiên trình sẽ như này, một thread được quyền update xuống shm, sau đó, release block. Context switch qua thread 2, update, release block. Context switch qua thread 3, update, release block...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

 

[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...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

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...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

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:
https://winterbe.com/posts/2015/04/30/java8-concurrency-tutorial-synchronized-locks-examples/

ps còn một số ngôn ngữ khác có concurrent nhưng không có locking mechanism thì một là nó là single thread không cần thiết (js), hai là nó global intepreter lock (ruby, python).

À, ý 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...
32 lần context switch để thực thi update shm.
shm variable lưu vào thread cache. Có 1 vấn đề xảy ra, một là data not consistent, data local của bác sẽ delay so với main memory. Bác thật sự định read mà không lock ư.
Tóm lại, ở mục tương tác shm, bác chỉ có thể thực hiện tuần tự ở đó.
Mình đang đưa ra một cách để không phải sharre memory. Vì kiểu gì chẳng tuần tự, mình đưa nó vào một thread riêng.
Bác chỉ ra giúp mình, mình sai ở đâu nhỉ.

cái thread chứa data của bạn lúc này đóng vai trò là shared memory rồi :v

mà giải pháp của bạn thường người ta gọi là actor model, cũng là một cách giải quyết của concurrent.

cơ mà tuỳ thuộc bài toán cụ thể mà cách này ngon hơn cách kia, actor model nó tương tác với nhau bằng message passing, message mà nhỏ thì ok, nhưng nhiều bài toán xử lý dữ liệu lớn (number crunching) thì rõ ràng shared memory hiệu quả hơn hẳn.

 

[prescolt]

Tài liệu này hay cho mấy vụ thread, ipc. Mấy bạn dev nào mới vào nghề, thay vì lao vào code như thiêu thân thì nên xem qua những tài liệu này.
https://cs.rochester.edu/courses/456/fall2014/slides/04-IPC.pdf

 

[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.
Khi bác update, bác phải block, đúng không. 32 thread update đồng thời, bác phải thực hiện 32 context switch để có thể update. Bác hiểu context switching đúng hem. Tức là, bác phải update tuần tự, không thể song song. Bác cũng không thể read từ local thread đơn thuần, thưa bác. Mà bác phải đi so sánh xem có action update không, bác mới được phép read từ local.

 

[prescolt]

Bác ơi, không đâu. Nó là kiểu event driven kinh điển thôi.
Khi bác update, bác phải block, đúng không. 32 thread update đồng thời, bác phải thực hiện 32 context switch để có thể update. Bác hiểu context switching đúng hem. Tức là, bác phải update tuần tự, không thể song song. Bác cũng không thể read từ local thread đơn thuần, thưa bác. Mà bác phải đi so sánh xem có action update không, bác mới được phép read từ local.

đã 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ả.
multi threaded (multi cpu core) thì cùng một lúc có thể có 2 task cùng access một đoạn dữ liệu, gây ra race condition hoặc deadlock, lúc đó cần có cơ chế để giải quyết vấn đề này. và cái này là bắt buộc cần có luôn, dù rằng bạn có dùng actor model hay không (nhưng ngôn ngữ nó thể ẩn đi không cho phép bạn truy cập cái này, aka non feature).

 

[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 threaded (multi cpu core) thì cùng một lúc có thể có 2 task cùng access một đoạn dữ liệu, gây ra race condition hoặc deadlock, lúc đó cần có cơ chế để giải quyết vấn đề này. và cái này là bắt buộc cần có luôn, dù rằng bạn có dùng actor model hay không (nhưng ngôn ngữ nó thể ẩn đi không cho phép bạn truy cập cái này, aka non feature).

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.
với lại cũng tuỳ cách bạn thiết kế nữa, dùng 1 channel hay dùng nhiều channel kết hợp để lưu shared memory.

 

[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.
Vài khi đọc thì sẽ flush shared memory, thread nào nhận packet có destination 1.1.1.1 trước và expire time tới hạn thì sẽ update shared memory pool tương ứng 1.1.1.1, trong qua trình update thì mấy thread còn lại nếu cũng nhận 1.1.1.1 thì dữ liệu sẽ rỗng luc đó thì sẽ có bảng memory của riêng thread đọc từ file lên, như vậy sẽ giải quyết được vấn đề block ở shared mem. Nếu lúc nào cũng đọc file thì block cao hơn, và đọc từ file thì không có timeout như đọc từ TCP, io mà dẹo thì rất dễ dead lock

 

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