Bài giảng về thời gian thực: Lập lich (Scheduling)

[Vo_Duy_Thanh]

Đã lâu lắm rồi ko có bài nào cả. Hôm nay gửi các bạn phương thức lập lịch trong lập trình thời gian thực.
Bài này có cách trình bày khác với của TS. Hoàng Minh Sơn. Theo mình thì bài này đơn giản hơn và căn bản hơn.

Bài giảng tiếp theo mình sẽ trình bày là Kernel Sevice (các dịch vu của Kernel) và có thể sẽ nói về truyền thống giữa các tác vụ.

[anhtuan133]

Vấn đề sched là vấn đè trung tâm của kernel. Trong tài liệu này nói rất rõ ràng rồi. Nhưng vấn đề dành cho người viết ra kernel ấy, tức là phải dùng giải thuật như thế nào để xác định xem task nào sẽ được chạy, cái này phải tính toán chi li từng lệnh asm đấy.
Mình có một ý, đó là việc khống chế công suất tính toán cho task. Giả sử ta muốn một nhóm task nào đó hoạt động thật ít, còn một nhóm task khác phải hoạt động thật nhiều. Việc thiết lập priority cũng không ổn vì phát sinh vấn đề dead task, và sự khống chế ở đây cũng không rõ ràng, cụ thể là khoảng bao nhiêu phần trăm công suất tính toán được dành cho task. Theo ý mình có thể chia task queue thành layers. Layers 1 có mức ưu tiên cao nhất, switch task hết 10 vòng rồi mới chuyển sang Layer2, tức là tỉ lệ thực thi của task trong layer2 = 1/10 của layer1. Trong nội bộ 1 layer sẽ có sự phân chia priority theo cách thông thường.
Với cách làm này bạn có thể giảm thiểu việc trễ trong các yêu cầu cần đáp ứng nhanh. Ví dụ việc giám sát vị trí của tay robot không bị phần task truyền thông ảnh hưởng quá nhiều. Bạn có thể thấy điều này khi ai đó download từ máy bạn ra qua Ethernet làm máy bạn chạy chậm hẳn đi mà bạn không có cách nào khống chế được tốc độ download đó cả, dẫn tới việc máy bạn có vẻ đơ đơ, nếu như bạn khống chế được việc thực thi truyền thông chỉ được chiếm khoảng 10% công suất CPU thì công suất của CPU sẽ chủ yếu dành cho bạn.
Các bạn thử cho ý kiến về cách sched này nhé.

[anhtuan133]

Một vấn đề nữa đó là tại một task nào đó có mức ưu tiên thấp nhưng lại có 1 action đòi hỏi rất chặt về thời gian, ví dụ sau khi đã bật chân IO1 lên thì phải tắt nó đi sau chính xác 5 time ticks. Để giải quyết, ta có thể cấm ngắt, hoặc đặt lại priority.... Tôi đưa ra một giải pháp, đó là phần switch task của kernel sẽ cung cấp 1 vé VIP, nếu task nào đăng ký vé VIP đó thì sau 1 số time tick yêu cầu thì task đó sẽ được active. Và priority của task không hề phải thay đổi.

[anhtuan133]

Còn một ý nữa đó là thời điểm xác định chuyển task trong cơ chế round-robine. Giả sử 1 task dùng hàm chuyển task ngay gần sát thời điểm time tick sẽ gây sai lệch về thời gian của hệ thống (nếu dùng time tick làm dơn vị thời gian). Nhất là với những hệ thống dùng timer software reload thì sau 1 ngày chạy sẽ thấy thời gian sai đi rất nhiều.
Vấn đề trôi thời gian cũng xảy ra nếu user sử dụng các ngắt không đồng bộ (ngắt cứng) có mức ưu tiên cao hơn ngắt timer tạo time tick. Việc sử lý triệt để vấn đề này có lẽ sẽ tốn thêm một ít code nữa

[anhtuan133]

Vấn đề đau đầu tiếp theo chính là hàm Delay(). Trong cách lập trình thông thường hàm Delay() thường chạy không chính xác là do sự xuất hiện các ngắt cứng, còn trong lập trình đa nhiệm nó càng chạy sai hơn vì cơ chế switch task. Do đó xuất hiện nhu cầu dùng delay theo đơn vị là time tick. Đối với uC thì time tick thường khoảng 1ms, mà nhu cầu dùng các hàm delay_ms(5), delay_ms(10).... thường rất nhiều, tức là thời gian delay tương đối gần với thời gian switch task. Vậy làm thế nào để delay_ms(5) không biến thành delay_ms(8)? Lại phải thêm 1 số code nữa vào kernel thôi.

[qmk]

anhtuan133 đáng rối vì định tự xây dựng RTOS đây mà.
Vấn đề 5-10 stick kô có vấn đề gì cả.
Còn đã làm trên RTOS ít ai mà timer mềm kiểu delay như vậy cả. Ví dụ như sleep(5ms) chẳng hạn khi gặp hàm này RTOS sẽ switch sang task khác và schedule để chạy tiếp task sau khoảng 5ms.