Làm thế nào đến RTOS được coi là xác định?

Trên một máy tính (tất nhiên là một hệ điều hành), bất kỳ chương trình C nào cũng trở nên không xác định về mặt thời gian. Chẳng hạn, một vòng lặp mất từ ​​1,2 đến 1,3 giây tùy thuộc vào "tốc độ tôi di chuyển một cửa sổ khác". Đó là bởi vì HĐH làm cho các tiến trình (hoặc luồng) chia sẻ sức mạnh xử lý.

Theo như RTOS (trên một hệ thống nhúng), khi chúng ta viết một ứng dụng đa luồng, tôi nghĩ điều tương tự xảy ra tùy thuộc vào số lượng luồng đang thực thi đồng thời.

Tôi không có công cụ để kiểm tra chính xác điều này trên một hệ thống nhúng. Vì vậy, tôi muốn hỏi. Là mối quan tâm của tôi hợp lý hay tôi đang thiếu một cái gì đó rất cơ bản?

EDIT : Tôi sẽ đưa ra một ví dụ. chúng ta có task1 (mất 10 ms) và task2 (mất 20 ms). Họ bắt đầu cùng một lúc trên hai chủ đề riêng biệt. Yêu cầu của tôi (cũng quan tâm, không chắc chắn) là task1 mất hơn 10ms, vì chúng chia sẻ sức mạnh xử lý với task2.

Không đúng khi các tác vụ trong RTOS tự động xác định, nhưng có thể đặt các ràng buộc chặt chẽ hơn nhiều về thời gian và tần suất các tác vụ chạy. Một RTOS thường sẽ cung cấp các ưu tiên cứng cho các nhiệm vụ; bất cứ lúc nào nhiệm vụ sẵn sàng với ưu tiên cao nhất đang chạy. Tác giả của mã cũng có toàn quyền kiểm soát tập hợp các tác vụ đang chạy; bạn có thể mong đợi một cách hợp lý rằng không có tác vụ nền ưu tiên cao nào có thể làm gián đoạn mã của bạn, giả sử, trao đổi dữ liệu vào đĩa, trừ khi bạn đã viết chúng.

Trên hết, một số RTOS cung cấp cho đa nhiệm hợp tác. Trái ngược với đa nhiệm phủ đầu, với đa nhiệm hợp tác, một tác vụ sẽ tiếp tục thực thi cho đến khi nó tự nguyện từ bỏ quyền kiểm soát CPU.

Theo như RTOS (trên một hệ thống nhúng), khi chúng ta viết một ứng dụng đa luồng, tôi nghĩ điều tương tự xảy ra tùy thuộc vào số lượng luồng đang thực thi đồng thời.

ĐẠO ĐỨC!

Nếu điều đó xảy ra, thì đó không phải là HĐH THỜI GIAN (RTOS).

Câu trả lời ngắn gọn là định nghĩa của RTOS không liên quan gì đến đa tác vụ hoặc ưu tiên. Nó chỉ đơn giản là tất cả các nhiệm vụ có đảm bảo thời gian .

Phần còn lại của những gì bạn coi là đặc điểm của RTOS (ưu tiên, hoàn thành nhiệm vụ, v.v.) chỉ là hậu quả (hoặc tính năng) của việc xây dựng một hệ thống trong đó các nhiệm vụ phải hoàn thành trong khoảng thời gian được chỉ định.

Đa tác vụ trong RTOS đơn giản hơn về mặt khái niệm so với HĐH thời gian mềm vì nhiều trường hợp cạnh phức tạp về cơ bản không được phép.

RTOS thường không đảm bảo thông lượng , thay vào đó, nó cho phép bạn đảm bảo độ trễ .

Điều này thường đạt được bởi một hệ thống ưu tiên, chẳng hạn như ở đây trong FreeRTOS:

Bộ lập lịch FreeRTOS đảm bảo rằng các tác vụ ở trạng thái Sẵn sàng hoặc Chạy sẽ luôn được dành thời gian cho bộ xử lý (CPU) theo các ưu tiên cho các tác vụ có mức độ ưu tiên thấp hơn cũng ở trạng thái sẵn sàng. Nói cách khác, tác vụ được đặt trong trạng thái Chạy luôn là tác vụ ưu tiên cao nhất có thể chạy.

Giả sử bạn có một nhiệm vụ ưu tiên 1 mất 10ms để xử lý một sự kiện, một nhiệm vụ ưu tiên 2 mất 100ms để xử lý một sự kiện khác nhau và nhiệm vụ 3 ưu tiên nền. Nếu bạn đang mong đợi nhận được một sự kiện ưu tiên 1 không quá mỗi giây, bạn có thể nói rằng trường hợp xấu nhất để xử lý sự kiện ưu tiên 2 là 10ms + 100ms. Nhiệm vụ ưu tiên 3 có thể bị làm chậm tùy ý bởi các sự kiện, nhưng bạn không quan tâm - vì đó là mức độ ưu tiên thấp.

Tôi muốn thay vì đây là một bình luận nhưng cần quá nhiều nhân vật. Dù sao, ozgur, đánh giá bằng các câu hỏi trong câu trả lời nhận xét của bạn, bạn dường như đang thiếu điểm mà bạn không thể đơn giản nói rằng chủ đề của tôi mất nhiều thời gian để chạy và mong đợi nó hoạt động kỳ diệu cùng với các chủ đề khác nhờ vào HĐH. Bạn phải thiết kế các chủ đề của bạn và phân tích chúng cho hiệu suất trường hợp xấu nhất. Nếu trường hợp xấu nhất không đáp ứng yêu cầu của bạn thì bạn cần thiết kế lại chủ đề của mình.

Vì vậy, thay vì chỉ đơn giản là nói luồng 1 mất 10 ms để hoàn thành và luồng 2 mất 20 ms, bạn cũng phải nói luồng 1 phải thực hiện cứ sau 15 ms. luồng 2 phải thực thi cứ sau 40 ms. thread 3 phải thực thi cứ sau 500 ms, threadN phải thực thi sau mỗi 1500 ms. Sau đó, bạn phân bổ thời gian cho mỗi luồng có thể mất bao lâu để hoàn thành trong trường hợp xấu nhất. Bạn đặt tất cả những thứ đó lại với nhau, xác định các tình huống xấu nhất có thể xảy ra và sau đó bạn phải đảm bảo mọi luồng đều đáp ứng các yêu cầu về thời gian của nó. Phân tích này cũng là nơi bạn xác định nếu một số chủ đề cần được ưu tiên cao hơn các chủ đề khác để đáp ứng yêu cầu về thời gian của chúng.

Ví dụ, luồng 5 đang chạy bị gián đoạn bởi luồng 4 bị gián đoạn bởi luồng 3 bị gián đoạn bởi luồngN có thể là một trường hợp xấu nhất. Bạn đặt tất cả điều này lên dòng thời gian và xác minh rằng ngay cả trong trường hợp xấu nhất này, mọi luồng đều đáp ứng các yêu cầu về thời gian của nó. Bạn có thể đảm bảo các luồng hoàn thành kịch bản trường hợp xấu nhất này một cách xác định bằng cách sử dụng bộ lập lịch và các ưu tiên trong HĐH thời gian thực. Sự quyết định đó là những gì tạo nên một hệ điều hành thời gian thực.

Nếu bạn tạo các luồng có cùng mức độ ưu tiên thì bạn đã mất một số (nếu không phải tất cả) tính xác định đó bởi vì trình lập lịch biểu có thể được tự do chọn bất kỳ luồng nào mà nó muốn chạy tiếp theo.

Trong một hệ điều hành như Windows, bạn không chỉ không thể chỉ định khi nào mỗi luồng sẽ chạy, thậm chí bạn không thể đảm bảo rằng ứng dụng của bạn sẽ chạy bất cứ lúc nào. HĐH có thể tạm dừng ứng dụng của bạn và chạy một số dịch vụ nền bất cứ khi nào nó chọn. Nói cách khác, không có tính quyết định. Do đó, Windows không phải là một hệ điều hành thời gian thực. Mặc dù, nếu yêu cầu về thời gian của bạn lớn, như (thread1 chạy cứ sau 10 giây, thread2 chạy cứ sau 15 giây) thì về cơ bản bạn có thể đối xử với Windows như một hệ điều hành thời gian thực miễn là bạn tính đến việc trượt và cứ sau 10 hoặc 15 giây (cho hoặc mất vài trăm mili giây và một cửa sổ thỉnh thoảng bị bỏ lỡ) là đủ tốt.

Mặc dù các câu trả lời khác đã tuyên bố rằng trong "thế giới thực", kịch bản của bạn là không thể, nhưng để có thể trả lời câu hỏi của bạn, chúng tôi phải xây dựng một hệ thống giả thuyết .

Hệ thống của chúng tôi bao gồm một khẩu súng bắn bóng với tốc độ ổn định, hai hộp "bắt" bóng và tiến lên một bước với mỗi quả bóng bắt được. Súng có thể được chuyển sang bắn vào một trong các hộp nhưng nó mất một quả bóng mỗi khi nó được chuyển. Hộp đầu tiên sẽ cần 1000 bước (bóng) để đi đến cuối và hộp 2 sẽ cần 2000.

Kịch bản 1 (nhiệm vụ lần lượt):
- súng bắn 1000 quả bóng vào hộp 1, công tắc (tốn 1 quả bóng) và bắn 2000 quả bóng vào hộp 2, với tổng số 3001 quả bóng .

Kịch bản 2 (nhiệm vụ "đồng thời"):
- súng bắn 5 quả bóng vào một hộp, chuyển đổi và bắn 5 quả bóng vào hộp kia để tạo ra sự đồng thời . Chi phí chuyển đổi là (1000/5 x 2 =) 400 quả bóng. Vì vậy, sau khi bắn 2400 quả bóng, hộp 1 sẽ đi đến điểm cuối của nó và hộp 2 sẽ cần thêm 1000 quả bóng để đi đến điểm cuối của nó, với tổng số 3400 quả bóng .

Áp dụng các kết quả này vào kịch bản của bạn, Nhiệm vụ 1 và nửa đầu của Nhiệm vụ 2 sẽ hoàn thành sau 24 ms và nửa sau của Nhiệm vụ 2 sẽ hoàn thành trong 10ms nữa trong tổng số 34ms. Điều này cho thấy rõ rằng thời gian cần thiết để hoàn thành các nhiệm vụ tăng lên do thời gian bị mất trong quá trình chuyển đổi giữa các nhiệm vụ . Các kết quả này cũng tương đương với Nhiệm vụ 1 mất 12ms và Nhiệm vụ 2 mất 22ms, để hoàn thành.