Máy nhà nước vs chủ đề

Alan Cox đã từng nói "Máy tính là một máy trạng thái. Chủ đề dành cho những người không thể lập trình máy trạng thái".
Vì hỏi trực tiếp Alan không phải là một lựa chọn để tôi khiêm tốn, tôi muốn hỏi ở đây: làm thế nào để đạt được chức năng đa luồng trong ngôn ngữ cấp cao, chẳng hạn như Java, chỉ sử dụng một luồng và máy trạng thái? Ví dụ: nếu có 2 hoạt động để thực hiện (thực hiện tính toán và thực hiện I / O) và một hoạt động có thể chặn thì sao?
Là sử dụng cách "máy chỉ nhà nước" thay thế khả thi cho đa luồng trong các ngôn ngữ cấp cao?

Tất cả một luồng thực hiện là các hoạt động xen kẽ để các phần của quá trình dường như trùng lặp về thời gian. Một máy lõi đơn có nhiều luồng chỉ nhảy xung quanh: nó thực thi các bit mã nhỏ từ một luồng, sau đó chuyển sang luồng khác. Một bộ lập lịch đơn giản quyết định chủ đề nào là ưu tiên cao nhất và thực sự được thực thi trong lõi.

Trên một máy tính lõi đơn, không có gì thực sự xảy ra "cùng một lúc". Tất cả chỉ là sự thực thi xen kẽ.

Có rất nhiều, nhiều cách để đạt được xen kẽ. Nhiều.

Giả sử bạn có một quy trình hai luồng đơn giản sử dụng khóa đơn giản để cả hai luồng có thể ghi vào một biến chung. Bạn có sáu khối mã.

• Khóa trước
• T1-có khóa
• Khóa sau
• Khóa trước
• T2-có khóa
• Khóa sau T2

[Điều này có thể trong một vòng lặp hoặc có nhiều khóa hoặc bất cứ điều gì. Tất cả những gì nó làm là lâu hơn, không phức tạp hơn.]

Các bước của T1 phải chạy theo thứ tự (T1-trước, T1-with, T1-after) và các bước của T2 phải chạy theo thứ tự (T2-trước, T2-with, T2-after).

Khác với ràng buộc "theo thứ tự", chúng có thể được xen kẽ theo bất kỳ cách nào. Dù sao. Họ có thể được chạy như được liệt kê ở trên. Một thứ tự hợp lệ khác là (T1-trước, T2-trước, T2-lock, T1-lock, T2-after, T1-after). Có rất nhiều thứ tự hợp lệ.

Chờ đợi.

Đây chỉ là một máy trạng thái với sáu trạng thái.

Đó là một automata trạng thái hữu hạn không xác định. Thứ tự của các trạng thái T1-xxx với các trạng thái T2-xxx là không xác định và không thành vấn đề. Vì vậy, có những nơi "trạng thái tiếp theo" là tung đồng xu.

Ví dụ: khi FSM bắt đầu, T1-trước hoặc T2-trước đều là các trạng thái đầu tiên hợp pháp. Tung đồng xu.

Hãy nói rằng nó đã xuất hiện trước đây. Làm vậy đi. Khi đã xong, có một sự lựa chọn giữa T1-với và T2-trước. Tung đồng xu.

Ở mỗi bước trong FSM sẽ có hai lựa chọn (hai luồng - hai lựa chọn) và một lần tung đồng xu có thể xác định trạng thái cụ thể nào được tuân theo.

Viết các chức năng chặn dành cho những người không thể tạo ra các máy trạng thái;)

Chủ đề rất hữu ích nếu bạn không thể có được xung quanh chặn. Không có hoạt động cơ bản nào trên máy tính thực sự bị chặn, chỉ có rất nhiều trong số chúng được triển khai theo cách đó để dễ sử dụng. Thay vì trả về một ký tự hoặc "đọc thất bại", một khối chức năng đọc cho đến khi toàn bộ bộ đệm được đọc. Thay vì kiểm tra tin nhắn trả về trong hàng đợi và trả về nếu không tìm thấy, hàm kết nối sẽ chờ trả lời.

Bạn không thể sử dụng các chức năng chặn trong máy trạng thái (ít nhất một chức năng không được phép "đóng băng").

Và có, sử dụng máy trạng thái là một thay thế khả thi. Trong các hệ thống thời gian thực, đây là tùy chọn duy nhất, hệ thống cung cấp khung cho máy. Sử dụng các luồng và các chức năng chặn chỉ là "cách dễ dàng", bởi vì thông thường một cuộc gọi đến chức năng chặn sẽ thay thế khoảng 3-4 trạng thái trong máy trạng thái.

Làm thế nào để một người đạt được chức năng đa luồng trong ngôn ngữ cấp cao, chẳng hạn như Java, chỉ sử dụng một luồng và máy trạng thái? Ví dụ: nếu có 2 hoạt động để thực hiện (thực hiện tính toán và thực hiện I / O) và một hoạt động có thể chặn thì sao?

Những gì bạn mô tả được gọi là đa nhiệm hợp tác , trong đó các tác vụ được cung cấp cho CPU và dự kiến ​​sẽ từ bỏ nó một cách tự nguyện sau một khoảng thời gian hoặc hoạt động tự xác định. Một tác vụ không hợp tác bằng cách tiếp tục sử dụng CPU hoặc bằng cách chặn toàn bộ công việc và không có bộ đếm thời gian theo dõi phần cứng, không có mã nào giám sát các tác vụ có thể làm về nó.

Những gì bạn thấy trong các hệ thống hiện đại được gọi là đa nhiệm được ưu tiên , đó là nơi các tác vụ không phải từ bỏ CPU vì người giám sát thực hiện việc đó cho chúng khi có sự gián đoạn do phần cứng tạo ra. Thói quen phục vụ ngắt trong trình giám sát sẽ lưu trạng thái của CPU và khôi phục lại lần sau khi tác vụ được coi là xứng đáng với một lát cắt thời gian, sau đó khôi phục trạng thái từ bất kỳ nhiệm vụ nào sẽ được chạy tiếp theo và nhảy trở lại như thể không có gì xảy ra . Hành động này được gọi là chuyển đổi ngữ cảnh và có thể tốn kém.

Là sử dụng cách "máy chỉ nhà nước" thay thế khả thi cho đa luồng trong các ngôn ngữ cấp cao?

Khả thi? Chắc chắn rồi. Sane? Đôi khi. Cho dù bạn sử dụng chủ đề hay một số hình thức đa nhiệm hợp tác sản xuất tại nhà (ví dụ: máy trạng thái) tùy thuộc vào sự đánh đổi mà bạn sẵn sàng thực hiện.

Chủ đề đơn giản hóa thiết kế nhiệm vụ đến mức bạn có thể coi mỗi người là chương trình riêng của mình để chia sẻ không gian dữ liệu với người khác. Điều này cho phép bạn tự do tập trung vào công việc trong tay và không phải tất cả các quản lý và vệ sinh cần thiết để làm cho nó hoạt động lặp đi lặp lại tại một thời điểm. Nhưng vì không có hành động tốt nào không bị trừng phạt, bạn phải trả cho tất cả sự tiện lợi này trong các chuyển đổi ngữ cảnh. Có nhiều luồng mang lại CPU sau khi thực hiện công việc tối thiểu (tự nguyện hoặc bằng cách làm một cái gì đó sẽ chặn, như I / O) có thể ngốn rất nhiều thời gian của bộ xử lý khi thực hiện chuyển đổi ngữ cảnh. Điều này đặc biệt đúng nếu các hoạt động chặn của bạn hiếm khi chặn rất lâu.

Có một số tình huống mà tuyến đường hợp tác có ý nghĩa hơn. Tôi đã từng phải viết một số phần mềm người dùng cho một phần cứng truyền phát nhiều kênh dữ liệu thông qua giao diện được ánh xạ bộ nhớ yêu cầu bỏ phiếu. Mỗi kênh là một đối tượng được xây dựng theo cách mà tôi có thể cho phép nó chạy như một luồng hoặc liên tục thực hiện một chu kỳ thăm dò ý kiến.

Hiệu suất của phiên bản đa luồng không tốt chút nào vì chính xác lý do tôi đã nêu ở trên: mỗi luồng hoạt động tối thiểu và sau đó thu được CPU để các kênh khác có thể có thời gian, gây ra nhiều chuyển đổi ngữ cảnh. Để các luồng chạy miễn phí cho đến khi được ưu tiên giúp thông lượng nhưng dẫn đến một số kênh không được phục vụ trước khi phần cứng gặp lỗi tràn bộ đệm vì chúng không sớm có được một lát cắt thời gian.

Phiên bản đơn luồng, thậm chí lặp lại từng kênh, chạy như một con vượn bị bỏng và tải trên hệ thống giảm xuống như một tảng đá. Hình phạt mà tôi đã trả cho hiệu suất bổ sung là phải tự mình thực hiện các nhiệm vụ. Trong trường hợp này, mã để làm điều đó đủ đơn giản để chi phí phát triển và duy trì nó rất đáng để cải thiện hiệu suất. Tôi đoán đó thực sự là điểm mấu chốt. Nếu chủ đề của tôi là những người ngồi chờ đợi một số cuộc gọi hệ thống trở lại, bài tập có lẽ sẽ không có giá trị.

Điều đó đưa tôi đến nhận xét của Cox: chủ đề không dành riêng cho những người không thể viết máy trạng thái. Một số người hoàn toàn có khả năng làm điều đó nhưng chọn sử dụng một máy trạng thái đóng hộp (tức là một luồng) để hoàn thành công việc sớm hơn hoặc ít phức tạp hơn.

Điều gì xảy ra nếu có 2 hoạt động để thực hiện (thực hiện tính toán và thực hiện I / O) và một hoạt động có thể chặn?

Vâng, tôi thực sự không thể tưởng tượng làm thế nào để xử lý chặn I / O mà không có chủ đề. Nó được gọi là chặn sau tất cả chỉ vì mã gọi nó wait.

Theo tôi đọc email gốc của Cox (bên dưới), ông chỉ ra rằng việc phân luồng không có quy mô tốt. Ý tôi là, nếu có 100 yêu cầu I / O thì sao? 1000? 10000? Cox đang chỉ ra rằng có số lượng lớn các chủ đề có thể dẫn đến các vấn đề nghiêm trọng:

Từ: Alan Cox (alan@lxorguk.ukuu.org.uk)
Ngày: Thứ Sáu 21 tháng 1 năm 2000 - 13:33:51 EST

tài liệu của IBM), rằng nếu ứng dụng của bạn phụ thuộc vào số lượng lớn các luồng, bạn sẽ luôn tiếp tục chống lại trình lập lịch biểu? rất nhiều người ném rất nhiều chủ đề vào một vấn đề và nó thực sự có thể là thiết kế tồi.

Đó là điều ít lo lắng nhất của bạn. 1000 luồng là 8Mb ngăn xếp kernel và đủ chuyển đổi các tác vụ để đảm bảo bạn cũng có thể tắt hầu hết bộ nhớ cache. Một máy tính là một máy trạng thái. Chủ đề dành cho những người không thể lập trình máy trạng thái.

Có rất nhiều trường hợp Linux chắc chắn không giúp ích gì cho tình huống đáng chú ý là khối I / O không đồng bộ.

Alan

nguồn: Re: Phân tích thú vị về phân luồng nhân linux bởi IBM (lưu trữ danh sách gửi thư linux-kernel)

• Về lý thuyết, điều này đúng. Trong cuộc sống thực, các luồng chỉ là một sự trừu tượng hiệu quả được sử dụng để lập trình một máy trạng thái như vậy. Chúng hiệu quả đến mức chúng có thể được sử dụng để lập trình lưới Statecharts và Petri (nghĩa là các hành vi song song, trong đó các máy trạng thái về cơ bản là tuần tự).

• Vấn đề với máy móc nhà nước là nổ tổ hợp. Số trạng thái của máy tính có RAM 4G là 2 ^ (2 ^ 32) trạng thái (không tính ổ đĩa 2T).

• Đối với một người đàn ông có công cụ duy nhất là một cái búa, mọi vấn đề trông giống như một cái đinh.

Chủ đề là lựa chọn duy nhất trong hai trường hợp:

• để sử dụng nhiều lõi mà không cần tách bộ nhớ.
• để đối phó với mã bên ngoài mà chặn.

Thứ hai là tại sao hầu hết mọi người nghĩ rằng các luồng không thể tránh khỏi khi thực hiện IO hoặc lập trình mạng, nhưng điều này thường là do họ không biết HĐH của họ có API nâng cao hơn (hoặc không muốn chiến đấu với việc sử dụng nó).

Để dễ sử dụng và dễ đọc, luôn có các vòng lặp sự kiện (như libev hoặc EventMachine ) giúp lập trình một máy trạng thái gần như đơn giản như thực hiện với các luồng, nhưng vẫn có đủ quyền kiểm soát để quên các vấn đề đồng bộ hóa.

Một cách hay để tìm hiểu cách thức các máy trạng thái và đa luồng tương tác là xem xét các trình xử lý sự kiện GUI. Nhiều ứng dụng / khung GUI sử dụng một luồng GUI duy nhất sẽ thăm dò các nguồn đầu vào có thể và gọi một hàm cho mỗi đầu vào nhận được; về cơ bản, điều này có thể được viết như một chuyển đổi lớn:

while (true) {
    switch (event) {
        case ButtonPressed:
        ...
        case MachineIsBurning:
        ....
    }
}

Bây giờ, mọi thứ trở nên rõ ràng khá nhanh rằng mức độ kiểm soát cấp cao trong cấu trúc này không thể cao: Trình xử lý cho NútPress phải kết thúc mà không có sự tương tác của người dùng và quay lại vòng lặp chính, bởi vì nếu không, không có sự kiện người dùng nào nữa có thể được xử lý. Nếu nó có bất kỳ trạng thái nào để lưu, trạng thái này phải được lưu trong các biến toàn cục hoặc tĩnh, nhưng không phải trên ngăn xếp; đó là, luồng điều khiển bình thường trong một ngôn ngữ bắt buộc bị hạn chế. Bạn chủ yếu giới hạn trong một máy trạng thái.

Điều này có thể trở nên khá lộn xộn khi bạn có các chương trình con lồng nhau phải lưu, ví dụ, mức đệ quy. Hoặc đang ở giữa đọc một tệp, nhưng hiện tại tệp không có sẵn. Hoặc chỉ là trong một tính toán dài. Trong tất cả các trường hợp này, việc lưu trạng thái thực thi hiện tại và quay trở lại vòng lặp chính là điều mong muốn và đây là đa luồng . Không hơn không kém.

Toàn bộ sự việc trở nên phức tạp hơn một chút với sự ra đời của đa luồng được ưu tiên (tức là hệ điều hành quyết định khi nào các luồng sẽ mang lại quyền kiểm soát), và đó là lý do tại sao kết nối không rõ ràng ngay hôm nay.

Vì vậy, để trả lời câu hỏi cuối cùng: Có, máy trạng thái là một giải pháp thay thế, hầu hết các GUI hoạt động theo cách đó với luồng GUI. Chỉ cần không đẩy máy trạng thái quá xa, nó sẽ trở nên không thể nhận ra thực sự nhanh chóng.

Hỏi xem việc sử dụng máy trạng thái có khả thi trong ngôn ngữ cấp cao hay không, giống như hỏi liệu viết bằng trình biên dịch có phải là một thay thế khả thi cho việc sử dụng ngôn ngữ cấp cao hay không. Cả hai đều có vị trí của họ, đưa ra tình huống đúng.

Sự trừu tượng của việc sử dụng phân luồng làm cho các hệ thống song song phức tạp hơn dễ thực hiện hơn, nhưng cuối cùng tất cả các hệ thống song song đều có cùng một vấn đề cần giải quyết. Các vấn đề kinh điển như Deadlock / Livelock và đảo ngược ưu tiên là hoàn toàn có thể xảy ra với các hệ thống dựa trên máy trạng thái giống như với hệ thống bộ nhớ dùng chung song song , hệ thống dựa trên NUMA hoặc thậm chí CSP , nếu nó đủ phức tạp.

Tôi không nghĩ rằng - chắc chắn, máy trạng thái là một khái niệm điện toán rất 'thanh lịch' nhưng như bạn nói, chúng khá phức tạp. Và những điều phức tạp rất khó để có được đúng. Và những điều không đúng chỉ bị phá vỡ, vì vậy trừ khi bạn là thiên tài về tầm vóc được cho là của Alan Cox, hãy gắn bó với những thứ bạn biết - hãy để lại 'mã hóa thông minh' cho các dự án học tập.

Bạn có thể biết khi nào ai đó đã cố gắng thực hiện một cách vô ích, vì (giả sử nó hoạt động tốt) khi nói đến việc duy trì nó, bạn thấy rằng nhiệm vụ là không thể. 'Thiên tài' ban đầu sẽ chuyển sang để lại cho bạn một đống mã khó hiểu (vì các nhà phát triển kiểu này không có xu hướng để lại quá nhiều bình luận chứ đừng nói đến tài liệu kỹ thuật).

Một số trường hợp, máy trạng thái sẽ là lựa chọn tốt hơn - Tôi đang nghĩ đến công cụ loại nhúng hiện tại nơi một số mẫu máy trạng thái được sử dụng và được sử dụng nhiều lần và theo cách chính thức hơn (ví dụ kỹ thuật phù hợp :))

Việc phân luồng cũng có thể khó thực hiện, nhưng có những mẫu giúp bạn thực hiện - chủ yếu bằng cách giảm nhu cầu chia sẻ dữ liệu giữa các luồng.

Điểm cuối cùng về vấn đề này là các máy tính hiện đại vẫn chạy trên nhiều lõi, vì vậy một máy trạng thái sẽ không thực sự tận dụng tốt các tài nguyên có sẵn. Threading có thể làm một công việc tốt hơn ở đây.

Ví dụ điển hình về việc sử dụng máy trạng thái phù hợp thay vì chủ đề: nginx vs apache2. Nói chung, bạn có thể giả sử rằng nginx xử lý tất cả các kết nối trong một luồng, apache2 tạo một luồng trên mỗi kết nối.

Nhưng với tôi, việc sử dụng các máy trạng thái và các luồng khá giống nhau khi sử dụng asm vs java thủ công hoàn hảo: bạn có thể đạt được kết quả không thể hiểu được, nhưng phải mất rất nhiều nỗ lực của các lập trình viên, rất nhiều kỷ luật, làm cho dự án trở nên phức tạp và đáng giá hơn khi được sử dụng bởi rất nhiều lập trình viên khác. Vì vậy, nếu bạn là người muốn tạo một máy chủ web nhanh - hãy sử dụng máy móc trạng thái và IO không đồng bộ. Nếu bạn đang viết dự án (không phải thư viện sẽ được sử dụng ở mọi nơi) - hãy sử dụng các chủ đề.