1. Giới thiệu về RTOS

Fun fact cần được làm rõ

Không tồn tại câu chuyện một lõi CPU (core) có thể thực thi đồng thời hai tác vụ, mà thực tế các tác vụ đang thay phiên nhau một cách xen kẽ, tạo cảm giác nó đang chạy một cách “song song”, “đa nhiệm”.

Đặt vấn đề

Giả sử ai đó đang sử dụng một chiếc Oto lưu thông trên đường, bộ xử lí đang quản lí giữa hàng tá tác vụ thực thi “song song”. Không may, tai nạn xảy ra, làm sao tác vụ “bung túi khí” có thể ngay lập tức diễn ra để bảo vệ tài xế?

Bạn nghĩ đến giải pháp dành riêng một core cho việc xử lý những tình huống khẩn cấp? Vâng, tôi cũng đã từng nghĩ thế, tuy nhiên về mặt tối ưu chi phí thì đây không phải là một giải pháp tốt, trong hầu hết thời gian, core đó sẽ nhàn rỗi, gây lãng phí tài nguyên và tăng chi phí sản xuất. Yah tôi sẽ tìm một bài nghiên cứu nói về sự lãng phí này sẽ là như thế nào.

Tuy nhiên chúng ta còn có một giải pháp sắp tới mà tôi sẽ giới thiệu đây, không cần dành riêng một lõi CPU (core) nhưng vẫn đảm bảo được tốc độ và sự chính xác.

Quay lại câu chuyện gặp tai nạn trên đường, trong những tình huống khẩn cấp thế này cần một hệ điều hành có thể chọn và đưa ra tác vụ nào là ưu tiên nhất để thực hiện ngay lập tức mà không cần phải chờ đợi.

RTOS ra đời

RTOS (Real-Time Operating System) ra đời để giải quyết chính xác vấn đề này. Với khả năng xác định (determinism) và dự đoán được (predictability), RTOS đảm bảo rằng những tác vụ quan trọng như bung túi khí sẽ luôn được xử lý ngay lập tức mà không bị trì hoãn bởi các tác vụ khác.

Ở phần tiếp theo sẽ giải thích chi tiết hơn về hai đặc tính này của RTOS đã làm gì để việc bung túi khí được nhanh chóng, chính xác trong muôn ngàn các tác vụ đang diễn ra trên cùng một core.

2. Hai đặc tính: Predictability và determinism

Đây là quá trình chuyển đổi giữa 2 tác vụ trong RTOS, xảy ra do ngắt, ngắt này đóng vai trò như một tín hiệu khẩn cấp, báo cho bộ lập lịch rằng có một sự kiện quan trọng xảy ra, cần ưu tiên xử lý trước khi tiếp tục tác vụ khác.

Hai đặc tính này liên quan chặt chẽ với nhau nhưng không giống nhau.

3. Vì sao gọi là Hệ điều hành thời gian thực

Đúng như cái tên của nó, đây là một hệ điều hành hoạt động ở mức độ thời gian thực.

⁉️QA:

Các hệ điều hành chúng ta đang dùng (Windows, Linux,…) không “thực” sao?

⁉️QA:

RTOS “thực” đến mức nào, bản chất hệ điều hành thời gian thực được nhắc đến là gì?

Cần ghi nhớ câu này

Độ trễ giữa các tác vụ trên RTOS là không đổi, dù chúng ta có thêm bao nhiêu tác vụ đi nữa.

Câu hỏi thứ nhất: Vậy các hệ điều hành chúng ta đang dùng không “thời gian thực” sao?

Hệ điều hành chúng ta sử dụng hằng ngày như MacOS, Windows, Linux,… được gọi là GPOS (General-Purpose Operating System) cụ thể nó thế nào thì mình sẽ có một bài viết riêng sau ở đây nhé.

Bây giờ cứ hiểu nôm na nó là Hệ điều hành đa đa nhiệm, nó được thiết kế cho việc chú trọng vào thông lượng (số lượng tác vụ trong một đơn vị thời gian) và GPOS không thực sự đảm bảo yếu tố thời gian thực như mắt ta nhìn thấy, mà độ trễ này sẽ có thể ngày càng tăng khi chúng ta mở quá nhiều tác vụ cùng lúc. Điều này cũng khiến GPOS không có tính chất “thời gian thực”.

Câu hỏi thứ hai: Vậy RTOS thể hiện khả năng thời gian thực đến mức nào, và bản chất nó là gì?

Bản chất thì làm gì có một máy tính nào có thể vừa tính toán vừa thao tác nhanh đến mức “bằng” với thực tế được. Làm gì có một hệ thống túi khí nào nhanh đến mức vừa phát hiện tai nạn thì đã bung túi khí ngay lúc đó.

Có nghĩa trên thực tế RTOS vẫn tồn tại độ trễ giữa các tác vụ (thời gian cho việc chuyển tác vụ - context switching), nhưng nó được quản lí một cách nghiêm ngặt về độ trễ, tức độ trễ không đổi khi có ngày càng nhiều tác vụ xuất hiện, đồng thời cũng biết được độ trễ này chính xác là bao nhiêu (đối với lập trình viên). RTOS cũng có thể giúp đạt được độ trễ là rất nhỏ (≤ khả năng nhận ra và phản ứng con người) để có thể ứng dụng vào những tình huống cụ thể hơn với GPOS.

Phân loại RTOS

RTOS phân thành hai loại HARD và SOFT:

Hard Real-time Thời gian phản hồi tuyệt đối phải dưới giới hạn đã định, thường trong microseconds (μs) đến vài milliseconds (ms). Nếu trễ dù chỉ một chút, hệ thống có thể gặp lỗi nghiêm trọng (ví dụ: hệ thống túi khí xe hơi, điều khiển phanh ABS, hệ thống y tế).

Theo một số nghiên cứu, thời gian phản ứng của con người:

• Giải thích của não về xung 13-70ms
• Thời gian phản ứng nhanh nhất có thể 100-120ms
• Thời gian phản ứng trung bình (bình thường) >250ms

Ví dụ: Túi khí phải bung trong dưới 10 ms sau khi phát hiện va chạm.

Soft Real-time Thời gian phản hồi quan trọng nhưng không nhất thiết phải tuyệt đối chính xác, thường trong milliseconds (ms) đến vài seconds (s). Nếu có độ trễ nhỏ, hệ thống vẫn có thể hoạt động nhưng có thể kém hiệu quả hơn (ví dụ: truyền phát video, điều khiển động cơ không yêu cầu chính xác tuyệt đối).

Ví dụ: Hệ thống giải trí trên ô tô có thể chịu được độ trễ 100-500 ms mà không ảnh hưởng nghiêm trọng.

4. Các nội dung liên quan sẽ được thảo luận

1. So sánh RTOS và GPOS
2. Quá trình chuyển đổi giữa các task trong RTOS
3. Bức tranh tổng thể của hệ thống và RTOS
4. Ai sẽ làm việc với RTOS
5. Các giải pháp tương tự như barel level