Hệ điều hành thời gian thực RTOS

Chương 1: Hệ điều hành thời gian thực RTOS

CHƯƠNG 1: HỆ

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

ĐIỀU HÀNH THỜI GIAN THỰC (RTOS)

1.1 GIỚI THIỆU CHUNG: 1.1.1 Định nghĩa Hệ điều hành thời gian thực RTOS 1.1.1.1 Hệ thống thời gian thực ( Real time System):  Thời gian ( Time) :  Sự chính xác của hệ thống không chỉ phụ thuộc vào kết quả tính toán logic mà còn phụ thuộc vào thời gian cho ra kết quả.  Thực ( Real):  Đáp ứng của hệ thống với những sự kiện bên ngoài.  Thời gian thực ( Real-Time):  Phải đảm bảo các yếu tố :  Đáp ứng nhanh  Dự đoán được.  Các tác vụ ( Real-time Task) được xác định bằng deadline.  Deadline là thời gian tối đa một tác vụ PHẢI hoàn thành việc thính toán. 1.1.1.2 Thời gian thực cứng ( Hard Real-time) và thời gian thực mềm ( Soft Real-Time):

Hình 1.1: Thời gian thực cứng và thời gian thực mềm.

Page 1

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Thời gian thực cứng:  Một tác vụ là thời gian thực cứng nếu như thời gian tính toán vượt quá deadtime có thể gây ra sự phá vỡ môi trường điều khiển.  Thời gian thực mềm:  Một tác vụ là thời gian thực mềm nếu như đảm bảo thực thi trong deadtime cho phép và nếu như không đảm bảo thì sẽ không tạo ra những nguy hại nào đáng kể cho hệ thống và không làm ảnh hưởng đến sự ứng xử của hệ thống. 1.1.1.3 Định nghĩa hệ điều hành thời gian thực RTOS: Là hệ thống có:  Lịch trình thực thi theo thời gian.  Quản lý tài nguyên hệ thống.  Cung cấp những nền tảng cơ bản để phát triển các ứng dụng trên nó. 1.1.2 Các thành phần trong RTOS:

Hình 1.2 : Các đối tượng trong RTOS  Bộ lịch trình ( scheduler): Là một tập các thuật toán để xác định tác vụ ( Task) nào được thực thi .  Đối tượng (Object) : Là những cấu trúc đặc biệt (Kernel) giúp người lập trình tạo ra các ứng dụng.

Page 2

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Dịch vụ ( Service) : Là những điều khiển mà Kernel ( lõi) thực thi trong đối tượng ( object): chia thời gian ( Timing), Ngắt( interrupt), Đáp ứng ( handling) và quản lý tài nguyên hệ thống ( resource management) 1.1.2.1 Bộ lịch trình ( Scheduler):  Là một phần vô cùng quan trọng của lõi hệ thống điều khiển ( Operating System Kernel).  Nó giúp xác định tác vụ (task) nào sẽ dành quyền CPU để thực thi tiếp theo. Sau đó, nó thực hiện việc chuyển trạng thái ( context switching) được thực hiện bằng bộ điều phối ( dispatcher). 1.1.2.1.1

Chuyển đổi trạng thái ( Context Switching)

Hình 1.3 : Chuyển đổi trạng thái ( ngữ cảnh)  Trạng thái ( ngữ cảnh) của tác vụ ( Task)  Mỗi task có một trạng thái riêng của nó, nó chính là trạng thái của những thanh ghi ( registers).  Mỗi thời điểm 1 task mới được tạo ra , kernel sẽ tạo ra và lưu giữ một block điều khiển liên quan đến task đó ( TCBs ). TCBs là những cấu trúc dữ liệu hệ thống mà kernel dùng để lưu trữ những thông tin đặc trung của task. TCBs chứa mọi thứ mà một kernel cần để biết về một task cụ thể nào đó. Khi task đnag chạy, trạng thái của nó là động. Trạng thái động này được lưu trữ trong TCB. Khi task không còn chạy nữa, trạng thái sẽ bị đóng bang ( frozen) trong TCB, và được sử dụng cho lần thực thi tiếp theo của task.

Page 3

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Công tắc chuyển đổi trạng thái ( Context Switch):  Sẽ xãy ra khi bộ lịch trình ( scheduler) chuyển từ một trạng thái này sang một trạng thái khác.  Việc chuyển đổi trạng thái bao gồm:  Thời gian chuyển đổi: Là thời gian tiêu tốn để cho bộ lịch trình chuyển từ task này sang task khác. Nó không có liên quan nào đến các lệnh thực hiện trong task. Nếu một ứng dụng được thiết kế mà xảy ra chuyển đổi trạng thái thường xuyên thì có thể dẫn đến những thực thi không cần thiết. Vì vậy, nên thiết kế ứng dụng theo cách mà tạo ra ít chuyển đổi trạng thái nhất.  Khi nào chuyển đổi xãy ra: Mỗi khi ứng dụng tạo một lời gọi hệ thống ( System Call) , bộ lịch trình sẽ xác định rằng có cần chuyển đổi trạng tháu hay không. Khi bộ lịch trình xác định việc chuyển đổi là cần thiết thì sẽ gọi bộ phân phối ( dispatcher) để thực hiện việc chuyển đổi.  Ví dụ: Khi bộ thực thi của Kernel xác định cần dừng việc thực thi task 1 để chuyển qua trạng task 2 thì nó sẽ thực thi theo các bước sau: Kernel sẽ lưu thông tin trạng thái của Task 1  Load thông tin trạng thái của Task 2, task2 trở thành luổng ( thread) thực thi hiện tại. Trạng thái chuyển đổi của Task 1 sẽ được đóng bang trong khi Task 2 đang được thực thi, nhưng nếu như bộ chuyển đổi xác định cần chạy lại task 1 thì task 1 sẽ quay lại vị trí ngay trước khi nó bị chuyển đổi.

Page 4

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Hình 1.4: Ví dụ về Contex Switch

1.1.2.1.2 Bộ điều phối (Dispatcher):  Dòng thưc thi ( Flow of Execution): Tại bất kì thời điểm nào RTOS đang chạy, dòng thực thi sẽ chuyển đến 3 vùng: đến các Task ứng dụng ( application Task), đến một chương trình phục vụ ngắt ( ISR), hoặc đến Kernel.  Khi nào bộ phân phối được thực hiên:  Khi một Task hoặc ISR tạo một lời gọi hệ thống, dòng điều khiển sẽ chuyển đến Kernel để thực thi một trong số những thủ tục được cung cấp bởi Kernel.  Khi rời khỏi kernel, Dispatcher sẽ có trách nhiệm là chuyển lệnh điều khiển đến một trong số những Task ứng dụng.  Cách thực hiện như sau:  Không cần thiết để chuyển toàn bộ lệnh điều khiển đến cùng một task gọi System Call. Điều này sẽ được xác định bằng giải thuật phân chia thời gian biểu ( scheduling algorithms ) của bộ lịch trình ( scheduler).  Chuyển đổi thực thi từ một Task

Page 5

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Hình 1.5: Điều phối từ một Task  Tùy thuộc vào cách truy cập vào Kernel như thế nào mà dispatching sẽ xãy ra khác nhau. Khi một Task thực hiện một lời gọi hệ thống, dispatcher sẽ được sử dụng để thoát khỏi Kernel mỗi khi Lời gọi hệ thống được hoàn thành. Trong trường hợp này, dispatcher được dùng như một lời gọi của lời gọi ( call- by –call basic) để nó có thể hỗ trợ cho việc chuyển đổi trạng thái của Task. Bất kì Task nào cũng có thể gọi system call. Một hay nhiều Task có thể ở trạng thái sắn sàng cho thực thi.  Chuyển đổi thực thi từ 1 chương trình phục vụ ngắt(ISR):

Hình 1.6: Điều phối từ một ISR

Page 6

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Khi một ISR tạo một System Call, Dispatcher sẽ bị bỏ vô hiệu hóa cho đến khi ISR thưc thi xong. Quá trinh này sẽ đúng miễn là có đủ tài nguyên để chuyển đổi giữa các Task. Chuyển đổi trạng thái này sẽ không được diễn ra bởi vì ISR phải được thực thi xong mà không được ngắt bởi các Tasks. Sau khi ISR thực thi xong, Kernel sẽ thoát đến dispatcher để có thể điều phối đến đúng task thực thi tiếp theo. 1.1.2.1.3 Giải thuật cho lịch trình:  Lịch trình thay thế theo độ ưu tiên:

Hình 7: Giải thuật lịch trình theo độ ưu tiên.  Hầu hết các Real – time Kernel sử dụng giải thuật lịch trình thay thế theo độ ưu tiên ( preemptive priority- based scheduling) làm mặc định.  Các task sẽ được thực thi tại bất kì một thời điểm là task có độ ưu tiên cao nhất so với các task khác đang ở trạng thái sẵn sàng.  Real –Time Kernel hỗ trợ 256 cấp độ ưu tiên, với 0 là độ ưu tiên cao nhất và 255 là độ ưu tiên thấp nhất. Một số Kernel thì ngược lại với 255 là độ ưu tiên cao nhất và 0 là độ ưu tiên thâp nhất.  Với bộ chuyển đổi theo đọ ưu tiên, mỗi task phải có một độ ưu tiên, và task có độ ưu tiên cao nhất chạy đầu tiên. Nếu một Task có độ ưu tiên cao hơn task đang chạy trở nên sẵn sàng để chạy thì kernel sẽ ngay lập tức lưu lại trạng thái Task hiện tại và chuyển sang Task có độ ưu tiên cao hơn.  Mặc dù việc phân chia độ ưu tiên của Task được thực hiện khi task đó được tạo nhưng độ ưu tiên của Task là có thể thay đổi một cách linh động sử dụng Lời gọi do kernel cung cấp ( Kernel – provided Page 7

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

calls). Khả năng này dùng để thay đổi một cách linh động cho phép một ứng dụng nhúng có độ linh hoạt để ứng xử với sự kiện bên ngoài khi chúng xuất hiện, tạo ra một hệ thống thời gian thực và đáp ứng tốt. Lưu ý là việc sử dụng không đúng khả năng thay đổi độ ưu tiên này có thể dẫn đến đảo độ ưu tiên ( priority inversion), vùng chết ( deadlock), và có thể dẫn đến treo hệ thống ( system failure).  Ví dụ: ( Hình 7) Task 1 được thay thế bởi task 2 có độ ưu tiên cao hơn, task 2 được thay thế bởi task 3 có độ ưu tiên cao hơn, khi Task 3 hoàn thành, task 2 sẽ tiếp tục thực thi trạng thái ngay trước khi bị dành quyền thực thi. Tương tự, khi task 2 hoàn thanh thì Task 1 sẽ được tiếp tục thực thi (resumes).  Lịch trình theo Round- Robin( Gọi vòng)

Hình 1.8 : Lịch trình theo Round- Robin  Mỗi Task sẽ cùng chia sẻ thời gian thực thi của CPU. Round- Robin thuần túy không thỏa mãn yêu cầu của hệ thống thời gian thực bởi vì một hệ thống thời gian thực các task phải làm việc theo mức độ quan trong khác nhau.  Ví dụ : ( Hình 8)  Thay vì thay thế theo độ ưu tiên, các task round – robin được phân chia thời giant thực thi theo các khoảng thời gian ( time slice).  Vơi time slicing , mỗi task sẽ được thực thi trong một khoảng thời gian nhất định, và theo vong trong. Một bộ đếm thời gian sẽ giám sát thời gian của mỗi Task, tăng lên theo mỗi xung clock. Khi thời gian thực thi một task đã hết, bộ đếm sẽ bị xóa, và task này sẽ được đặt ở cuổi cùng của chu kì ( end of circle).

Page 8

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Nếu như một task round-robin bị thay thế bởi mọt task có độ ưu tiên cao hơn, thì bộ đếm thời gian sẽ lưu lại và phục hồi khi task bị thay thế dành quyền thực thi lại. 1.1.2.2 Các đối tượng ( Objects) trong RTOS:  Tasks: Là các luồng ( thread) thực thi cùng tồn tại và độc lập nhau có thể “ cạnh tranh” nhau để dành quyền thực thi.  Semaphores: Là đối tượng bắt sự kiện để đồng bộ giữa các tasks, có thể tăng hoặc giảm.  Message Queues: Là một kiểu cấu trúc dữ liệu được dùng để đồng bộ hóa hoặc trao đổi thông tin giữa các Tasks.  Real-time embedded applications: Là sự kết nối giữa các đối tượng của Kernel để giải quyết vấn đề thời gian thực như sự đồng thời, sự đồng bộ,và trao đổi dữ liệu 1.2 VẤN ĐỀ QUẢN LÝ CÁC TASKS: 1.2.1 Định nghĩa Tasks:

Hình 1.9: Sơ đồ cấu trúc của một Task cơ bản. Page 9

Chương 1: Hệ điều hành thời gian thực RTOS

1.2.2

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Task là một luồng thực thi độc lập mà có thể cạnh tranh chiếm quyền thực thi . Một ứng dụng được chia ra làm nhiều Tasks đồng thời ( Concurrent Task) để tối ưu khả năng đáp ứng vào ra trong luật thời gian.  Một Task được định nghĩa thuần túy là một tập các tham số và cấu trúc dữ liệu.  Các thành phần của một Task:  Khi được tạo ra, Task sẽ có tên, ID duy nhất, độ ưu tiên, một block điều khiển Task ( TCB), Stack, và Các thủ tục thực thi Task. Task hệ thống ( System Task): Bao gồm các Task sau:  Task khởi tạo ( Initialization or Startup Task) Khởi tạo hệ thống và tạo task khởi động hệ thống.  Task “Rỗi” ( Idle Task). Idle Task chạy theo chu kì rỗi của hệ thống ( idle cycles), được đặt ở độ ưu tiên thấp nhất. Thực thi một vòng lặp vô tận. Idle task chắc chắn rằng bộ đếm chương trình luôn luôn có giá trị cho trong trường hợp không có task nào thực thi. Kernel cho phép các thao tác được cấu hình bời người dùng ( developer) để chạy những yêu cầu đặc biệt : sleep mode …  Task “đăng nhập” ( Logging Task). Là tin nhắn truy cập vào hệ thống.  Task “Lỗi” ( Exception- Handling Task). Thực thi các trường hợp lỗi hệ thống hoặc ứng dụng.  Task “ sữa lỗi” ( Debug Agent Task). Cho phép sữa lỗi thông qua công cụ debug ( host debugger). Chú ý rằng các task hệ thống khác có thể được tạo ra trong quá trình khởi tạo, phụ thuộc vào các thành phần có trong kernel.

Page 10

Chương 1: Hệ điều hành thời gian thực RTOS 1.2.3

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Các trạng thái của một Task:

Hình 1.10 . Các trạng thái của một Task.  Trạng thái của một Task: Tại bất kì một thời điểm, mỗi task tồn tại một trong số những trạng thái nhỏ bao gồm: Sẵn sàng ( Ready), Đang thực thi ( Running), hoặc Khóa ( Blocked). Khi một hệ thống nhúng thời gian thực chạy, mỗi task thay đổi từ trạng thái này đến trạng thái khác theo quy luật logic của một mấy trang thái hữu hạn đơn giản ( Finite state machine (FSM)). Về cơ bản, 3 trạng thái chính được sử dụng trong hầu hết các hệ thống Kernel sử dụng phương pháplịch trình thây thế . ( preemptive – scheduling). 1.2.3.1 Trạng thái sẵn sàng ( Ready State): Task đã sẵn sàng thực thi nhưng chưa thể thực thi vì task có độ ưu tiên cao hơn đang chiếm quyền thực thi.  Khi một Task được tạo lần đầu tiên, Kernel sẽ tự động đặt task này vào trạng thái sẵn sàng.  Ở trạng thái này, Task sẽ dành quyền thực thi với các Task ở trạng thái sẵn sàng khác để chiếm thời gian thực thi của bộ vi xử lý.  Task ở trạng thái sẵn sàng không thề chuyển vào trạng thái Khóa( blocked) một cách trực tiếp. Một Task đầu tiên cần phải chạy để có thể gọi “blocking call”, blocking call là lời gọi đến một hàm mà không thể chạy đến việc hoàn thành ngay lập tức.

Page 11

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Đối với những Kernel chỉ hỗ trợ mỗi mức ưu tiên cho một Task duy nhất, giải thuật lich trình sẽ được chuyển thẳng tới Task có độ ưu tiên cao nhất sẵn sàng cho lần chạy tiếp theo. Với việc hiện thực theo cách này , Kernel giới hạn số lượng Task trong một ứng dụng tương ứng với số mức ưu tiên được hỗ trợ.  Tuy nhiên, hầu hết các kernel hỗ trợ nhiều hơn một Task cho mỗi mức ưu tiên trong một ứng dụng cụ thể nào đó. Trong trường hợp này, giải thuật lịch trình sẽ phức tạp hownvaf bao gồm cả việc lưu trữ một danh sách cá task ổ trạng thái sẵn sàng. Một số Kernel lưu giữ danh sách task ở trạng thái sẵn sàng một cách rời rạc cho từng độ ưu tiên; một số khác thì có một danh sách duy nhất.  Ví dụ: ( Hình 11)  Giả sử hệ thống sử dụng giải thuật lịch trình thay thế theo độ ưu tiên ( priority- based preemptive scheduling algorithm) với 255 mức ưu tiên và quy định mức ưu tiên 0( lowest) là mức ưu tiên cao nhất.  Trong ví dụ này, Task 1, 2, 3, 4 và 5 đang ở trạng thái sẵn sàng thực thi, và Kernel xếp hang chúng bằng trong dang sách các task sẵn sàng( task –ready list). Task 1 là task có độ ưu tiên cao nhất (70); task 2, 3, 4 là những Task có độ ưu tiên tiếp theo (80), và Task 5 có độ ưu tiên thấp nhất( 90). Các bước sau giải thích việc Kernel dùng danh sách này như thế nào:  Vì Task 1 có độ ưu tiên cao nhất nên nó là Task đầu tiên sẵn sàng để chạy. Kernel sẽ chuyển Task 1 từ danh sách Task sẵn sàng sang trạng thái đang thực thi.  Suốt trong quá trình thực thi, Task 1 tạo ra một Blocking call. Kết quả là Kernel chuyển Task 1 vào trạng thái Blocked. Tiếp theo, Task 2 có độ ưu tiên cao thứ 2 nên sẽ được chuyển vào trạng thái đang thực thi.  Tiếp theo, Task 2 gọi Blocking call. Kernel chuyển Task 2 vào trạng thái Blocked.Quá trình tương tự diễn ra cho Task 3.  Khi Task 3 thực thi, tài nguyên hệ thống được yêu cầu bởi Task 2. Kernel sẽ chuyển Task 2 vào trạng thái sẵn sàng và chèn vào cuối danh sách các trạng thái sẵn sàng ở độ ưu tiên là là 80. Task 3 vâc tiếp tục là Task hiện thời đang chạy.

Page 12

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi  Task 3 tại thời điểm này sẽ được chuyển đến trạng thái sẵn sàng và chèn sau Task 2 trong danh sách ( cùng độ ưu tiên là 80), đứng trước Task 5.

Hình 1.11 : ví dụ về trạng thái sẵn sàng của Task Trạng thái đang thực thi ( Running state): Task có độ ưu tiên cao nhất và đang chạy.  Ở hệ thống đơn vi xử lý ( Single – processor system), chỉ duy nhất một Task có thể chạy tại một thời điểm. Trong trường hợp này, khi Task được chuyển vào trạng thái đang thực thi, bộ xử lý lấy dữ liệu từ các thanh ghi ứng với với trạng thái của Task. Bộ xử lý có thể thực thi thực thi những lệnh trong Task và quản lý Stack liên quan.  Như đã đề cập đến trong phần 1.2.3.1, một Task có thể chuyển đến trạng thái sẵn sàng trong khi đang chạy. Khi một Task chuyển từ trạng thái đang chạy đến trạng thái Sẵn sàng, nó bị chiếm quyền thực thi bởi Task có độ ưu tiên cao hơn. Trong trường hợp này, Task bị chiếm quyền thực thi sẽ được đặt vào vị trí chính xác về mức ưu tiên trong danh sách các Task đang trạng thái sẵn sàng thực thi, và Task có độ ưu tiên cao hơn được chuyển từ trạng thái sẵn sàng sang trạng thái đang thực thi.  Không giống như một Task wor trạng thái sẵn sàng, Task ở trạng thái đang thực thi sẽ chuyển đến trạng thái Blcoked theo cách sau:

1.2.3.2

Page 13

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Bằng cách tạo ra một lời gọi yêu cầu một tài nguyên nhưng không có sẵn để đáp ứng.  Bằng cách tạo ra một lwoif gọi yêu cầu chờ một sự kiện xuất hiện.  Bằng cách tạo ra một yêu cầu để delay chính nó trong một khoảng thời gian nào đó. 1.2.3.3 Trạng thái Khóa ( blocked State)  Task yêu cẩu tài nguyên hệ thống nhưng chưa được đáp ứng, yêu cầu sẽ phải đợi cho đến khi sự kiện xuất hiện, hoặc delay một khoảng thời gian.  Tính năng của trạng thái blocked là rất quan trọng trong hệ thống thời gian thực vì nếu không có trạng thái này, Task có độ ưu tiên thấp hơn sẽ không thể thực thi được. Nếu Task có độ ưu tiên cao hơn không được thiết kế cho trạng thái Blocked, CPU bị treo có thể xãy ra.  Một Task có thề chuyền đến trạng thái Blocked chỉ khi tạo một blocking call, yêu cầu một số điều kiện khóa . Một Task ở trạng thái Blocked cho đến khi một số điều kiện blocking được thỏa mãn. Ví dụ như một Semaphore xác định được Task nào đang đợi để giải phóng trạng thái blocked, hoặc là một “tin nhắn” ( message) trong đó chứa Task đang đợi đến một Queue, hoặc thời gian delay cho Task đó đã hết….  Khi một Task được mở khóa ( unclocked), Task có thể chuyển từ trạng thái blocked sang trạng thái sẵn sàng chạy ( ready state).  Nếu Task được mở khóa có độ ưu tiên cao nhất , Task này sẽ chuyển trực tiếp đến trạng thái đang thực thi và sẽ chiếm quyền thực thi của Task hiện tại.  Hiện tượng “ CPU starvation”: Hiện tượng này xãy ra khi Task có độ ưu tiên cao nhất chiếm toàn bộ thời gian thực thi và Task có độ ưu tiên thấp hơn không thể chạy được. 1.2.3.4

Các trạng thái khác:  Một số Kernel định nghĩa những trạng thái khác như : trì hoãn ( suspended), Treo ( pended) và delay. Trong trường hợp này, pended và delay thực chất là trạng thái trung gian của trạng thái blocked. Một Task ở trạng thái Pended đang chờ một tài nguyên nào đó cần được giải phóng, một delay Task thì đang chờ thời gian delay kết thúc. Trạng thái suspended tồn tại với mục đích debugging hệ thống.  Kernel phải lưu trạng thái hiện tại của tất cả các Tasks trong hệ thống. Khi những lời gọi được tạo ra bởi các tác đang thực thi, bộ lịch

Page 14

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

trình sẽ xác đính Task nào cần thay đổi và thực hiện những sự thay đổi này.  Trong một số trường hợp, Kernel thay đổi trạng thái của một số Task nhưng không có việc chuyển trạng thái ( context switching) xuất hiện vì trạng thái của Task có độ ưu tien cao nhất không bị ảnh hưởng. Trong những trường hợp khác, những sự thay đổi trạng thái này dẫn đến một context switching bởi vì Task có độ ưu tiên cao nhất sẽ bị blocked và không còn có độ ưu tiên cao nhất nữa. Khi quá trình xử lý xãy ra, Task thực thi trước đó được chuyển đến trạng thái blocked hoặc sẵn sàng, và task có độ ưu tiên cao nhất mới sẽ được thực thi. 1.2.4

Các điều khiển liên quan đến Task: 1.2.4.1 Tạo một Task:  Task có thể được tạo từ 1 hoặc 2 bước: Create : đặt task vào trạng thái suspended state Start : chuyển Task vào trạng thái sẵn sàng Một số Kernel hỗ trợ “ user configurable hook thực thì việc tạo Task. Trạng thái Suspended: Giống như trạng thái blocked , trong đó Task bị suspended thì không ở trạng thái đang thực thi cũng như là sẵn sàng thực thi. User configurable hook là một “máy” ( mechanism) thực thi những hàm do ngưởi lập trình cung cấp, tại thời điểm của một sự kiện nhất cụ thể nào đó. 1.2.4.2

Xóa một Task:  Nhiều Kernel cho phép một Task có thể xóa một Task khác.  Quá trình xóa một Task: Dừng Task đó, Giải phóng bộ nhớ bằng cách xóa Task control Block và Stack.  Ví dụ: Giả sử một Task nào đó yêu cầu một semaphore để dành quyền truy cập vào cấu trúc dữ liệu. Trong khi Task đang thực thi trên cấu trúc dữ liệu này, Task bị xóa. Nếu không thi hành một cách thích hợp, Việc xóa Task đang thực thi có thể dẫn đến những kết quả sau:  Phá vỡ cấu trúc dữ liệu bởi những lệnh ghi chưa hoàn thành.  Không giải phóng được Semaphore, dẫn đến các Task khác không thể yêu cầu semaphore được

Page 15

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Một cấu trúc dữ liệu không thể truy cập được, vì semaphore không được giải phóng, kết quả là chúng ta bị mất bộ nhớ hoặc tài nguyên hệ thống.  Mất bộ nhớ xãy ra khi bộ nhơ được sử dụng nhưng không được giải phóng, kết quả là thệ thống sẽ dần dần không còn đủ bộ nhớ để chạy chương trình.  Mất tài nguyên xãy ra khi tài nguyên được sử dụng nhưng không bao giờ đươc giải phóng, kết quả là mất bộ nhớ vì mỗi tài nguyên chiếm môt vùng nhớ nhất định. 1.2.4.3 Lịch trình cho một Task  Kernel sẽ cung cấp các APIs cho việc điều khiển trạng thái của Task. Người lập trình có thể điều khiển trạng thái của Task như: hoãn (suspend), tiếp tục( resume), bắt đầu lại (restart), lấy độ ưu tiên, cài đặt độ ưu tiên, khóa preemtion, mở khóa reemption.  Sử dụng lịch trình bằng tay, người tập trình có thể suspend và resume Task từ một ứng dụng. Điều này quan trọng trong vấn đề debug hệ thống, hoặc là suspend Task có độ ưu tiên cao để Task có đợ ưu tiên thấp hơn có thể được thực thi.  Người lập trình có thể delay một Task, Lấy thông tin vể độ ưu tiieen cuat Task đó.

1.2.5

1.2.4.4 Lấy thông tin của một Task:  Kernel cung cấp những thủ tục cho phép người lập trình có thề lấy thông tin của Task trong ứng dụng : ID và TCB.  Việc xác định TCB chỉ là trạng thái tức thời của Task, vì trạng thái của Task là động. Cấu trúc cảu một Task:

Hình 1.12 Hiện thực cấu trúc của một Task Page 16

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 “Chạy đến kết thúc” Task ( Run – to – completion Task) Một ví dụ của Run – to – completion Task là Task khởi tạo ở cấp ứng dụng ( application level). Task khởi tạo có nhiệm vụ khởi tạo ứng dụng và tạo ra các dịch vụ, Tasks, và một số đối tượng của Kernel.  Vòng vô tận Task ( Enless-Loop Task) Một cấu trúc Enless-Loop Task bao gồm cả phần code khỏi tạo nhưng phần khởi tạo chỉ cần một lần, sau đó sẽ là vòn lặp vô tận. Một thành phần không thể thiếu của vòng lặp vô tận là một hay nhiều blocking call nẳm trong vòng lặp. Những blocking call này cho phép các Task có độ ưu tiên thấp hơn có thể chạy được. 1.3 VẤN ĐỂ VỀ QUẢN LÝ SEMAPHORE: 1.3.1 Vấn đề chia sẻ tài nguyên ( Resourse sharing) và đồng bộ hóa ( Synchronization): 1.3.1.1 Chia sẽ tài nguyên hệ thống:

Hình 1.13 : Chia sẽ tài nguyên hệ thống  Chia sẽ tài nguyên: Việc truy cập bời nhiều tasks phải được đồng bộ để duy trì sự thống nhất của việc chia sẻ tài nguyên. Quá trình này gọi là đồng bộ hóa, có quan hệ mật thiết đến “Chọn kênh” ( mutual exclusions) và vùng “ưu tiên” ( critical section).  “Chọn kênh” ( mutual exclusion) Chỉ một Task duy nhất tại mỗi thời điểm mới có thể truy cập vùng tài nguyên chia sẽ.  Vùng “ưu tiên” ( Critical sections): Là vùng code truy cập vùng tài nguyên chia sẽ.  Ví dụ:  Xét 2 Tasks đang cố gắng truy cập một vùng nhớ chia sẽ. Một Task nhận dữ liệu liên tục từ một cảm biến và ghi vào vùng nhớ này. Page 17

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Trong khi đó, Task kia có nhiện vụ hiển thị dữ liệu này, nó sẽ đọc liên tục vùng nhớ lưu dữ liệu để gửi dữ liệu ra thiết bị hiển thị.  Vấn đề nảy sinh là nếu như việc sử dụng vùng nhớ này không mang tính “ độc quyền” (exclusive) thì nhiều task sẽ lần lượt truy cập đến vùng nhớ này. Ví dụ khi Task chưa hoàn thành việc ghi dữ liệu trước khi task kia cố gắng đọc dữ liệu. Điều này dẫn đến nội dung hiển thị sẽ sai.  Vùng code mà Task nhận dữ liệu tử cảm biến và ghi vào vùng nhớ là một vùng “ưu tiên” (critical section). Tương tự cho đoạn code mà trong Task hiển thị đọc dữ liệu từ vùng nhớ này cũng là một vùng ưu tiên, vì 2 vùng này cùng truy cập vào một vùng tài nguyên hệ thống.

1.3.1.2 Đồng bộ hóa( Synchronization):

Hình 1.14 : Đồng bộ hóa  Một cách tổng quát, một Task phải đồng bộ hoạt động của nó với Task khác để việc thực thi đa luồng( multi- thread) được đảm bảo. Hoạt động đồng bộ đảm bảo rằng thứ tự thực thi các Task được sử dụng.  Ví dụ: Hình 14: Một đoạn code C2 trong Task 2 chỉ được chạy nếu một đoàn code C1 nào đó trong Task 1 được chạy trước. Trong trường hợp này, chúng ta dùng một semaphore nhị phân đơn giản( binary semaphore), để hiện thực việc đồng bộ hóa.

Page 18

Chương 1: Hệ điều hành thời gian thực RTOS 1.3.2

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Định nghĩa một Semaphore:

Hình 1.15. Semaphore  Đối tượng của Kernel có một hay nhiều luồng thực thi có thể yêu câu hoắc giải phóng cho mục đích đồng bộ.  Khi một semaphore được tạo ra lần đầu tiên, Kernel sẽ phân chia chúng đến một Block điều khiển semaphore( semaphore control block (SCB), với một ID duy nhất, một giá trị và một danh sách các Tasks đang ở trọng thái chờ ( task waiting list)  Một semaphore giống như một chìa khóa cho phép một Task có thể tiến hành một số lệnh điều khiển hoặc truy cập tài nguyên. Nếu Task nhận được semphore thì nó sẽ tiến hành những điều khiền dự định trước hoặc là truy cập đến tài nguyên .  Kernel sẽ giám sát số lần semaphore được nhận bằng cách sử dụng một biến đếm ( token count), Biến này có thể được khởi tạo giá trị khi semaphore được tạo. Khi một Task nhận được một Semaphore, biến đếm sẽ giảm và khi giải phóng semaphore thì biến này sẽ tăng lên. Nếu như biến đếm này bằng 0 thì nghĩa là không có task nào nhận semaphore.  Danh sách các task ở trạng thái chờ kiểm tra những Task bị blocked và chờ semaphore. Danh sách này có thể là FIFO hoặc là theo thứ tự ưu tiên.  Một Kernel hỗ trợ có thể nhiều loại semaphore : nhị phân( binary), đếm( counting), chọn kênh ( muxtual- exclusive) .

Page 19

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

1.3.2.1 Binary semaphore

Hình 1.16 : Binary semaphore  Có giá trị là 0 hoặc 1.  Giá trị 0: rỗng ( unavailable)  Giá trị 1: có sẵn ( available)  Binary semaphore được đối xử như là nguồn toàn cục, nghĩa là Task nào cũng có thể sử dụng được. 1.3.2.2 Counting semaphore

Hình 1.17 : Counting semaphore  Sử dụng một biến đêm cho phép semphore có thể đươc nhận và giải phóng nhiều lần. Khi được tạo,một counting semaphore , biến đếm cho biết số lượng semaphore co thể được sử dụng.  Một hoặc nhiều Task có thể nhận semaphore cho đên khi không còn một “mã thông báo” nào (token). Khi tất cả các token đã đươc “ lấy đi” , biến Page 20

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

đếm sẽ có giá trị là 0. Và counting semaphore sẽ chuyển từ trạng thái có sẵn( available) sang trạng thái không có sẵn ( unavailable).  Counting semaphore là nguồn toàn cục nên có thể được sử dụng bởi nhiều Tasks khác. 1.3.2.3 Mutex semaphore

Hình 1.18: Mutex Semaphore

 Là một semaphore nhị phân đặc biệt hỗ trợ “quyền sờ hữu” ( ownership), truy cập đệ quy, xóa Task an toàn, và một hay nhiều giao thức để trách vấn đề nội tại của bộ Mutex.  Trạng thái của Mutex là khóa ( locked) và mở khóa( unlocked). Một Mutex được tạo ra thì có trạng thái ban đầu là unlocked, khi đó nó được nhận bởi các Task. Sau khi được nhận, Mutex sẽ bị khóa. 1.3.3

Các điều khiền liên quan đến Semaphore:  Tạo một Task:  Binary: Trạng thái ban đầu, danh sách các Task ở trạng thái chờ.  Counting: giá trị biến đếm ban đầu, danh sách các task đang ở trạng thái chờ.  Mutex: Danh sách thứ tự các Task ở trạng thái chờ, đệ quy..  Xóa một Semaphore:  Xóa bởi bất kì một Task nào bằng cách xóa ID.  Task đang chờ chuyển sang mở khóa ( unblocked).  Nhận semaphore bị xóa thì sẽ xãy ra lỗi.  Không được xóa semaphore khi nó đang được sử dụng.  Nhận Semaphore: Page 21

Chương 1: Hệ điều hành thời gian thực RTOS

1.3.4

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Task :  Vòng lặp vô tận: task bị khóa đến khi có semaphore.  Chờ với thời gian timeout: Task bị khóa đi khi  Có semaphore  Hết thời gian time out.  Không chờ: Task không bị khóa.  Giải phóng:  Có thể được giải phóng từ Task hoặc ISR.  Mutex chỉ giải phóng bởi Task nào đang sở hữu nó.  Giải phóng không thành công dẫn đến mất quyền truy cập Mutex.  Xóa danh sách các Task chờ semaphore:  Gửi tín hiệu đến tất cả các Task ( broadcast)  Giải phóng toàn bộ Task đang chờ semaphore  Lấy thông tin:  Lấy thông tin Semaphore  Lấy thông tin về ID. Vấn đề sử dụng semaphore: 1.3.4.1 Tín hiệu đồng bộ:

Hình 1.19 : Semaphore được sử dụng làm tín hiệu đồng bộ  Hai Task chia có thể giao tiếp cho mục đích đồng bộ hóa mà không trao đổi dữ liệu. Ví dụ, môt binary semaphore có thể được sử dụng để hỗ trợ việc truyền những lệnh điều khiển.  Trong trường hợp này, binary semaphore không có sẵn ban đầu ( giá trị là 0), tWaitTask có độ ưu tiên cao hơn nên thực thi trước. Task này gửi yêu cầu nhận semaphore nhưng bị khóa vì semaphore chưa có sẵn( unavailable). Bước này cho phép Task có độ ưu tiên thấp hơn tSignalTask có cơ hội thực thi, tSignal phát ra một semaphore và mở khóa cho tWaitTask. Bởi vì độ ưu tiên của Task tWaitTask cao hơn tSignalTask, cho nên ngay khi semaphore được tạo ra thì tWaitTask sẽ chiếm quyền thực thi của Task tSignal và bắt đầu thực thi.

Page 22

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

1.3.4.2 Giám sát việc đồng bộ hóa

Hình 1.20: Sử dụng counting semaphore để giám sát sự đồng bộ  Đôi khi tỉ lệ số Task tạo ra tín hiệ thực thi nhiều hơn số task nhận tín hiệu. Với counting semaphore, task tạo tín hiệu có thể tiếp tục thực thi và tăng biến đếm lên trong không gian chính nó.  Giá trị đếm ban đầu là 0, Task có độ ưu tiên thấp hơn tWaitTask cố gắng nhận một semaphore nhưng bị khóa đến khi tSignalTask tạo ra một semaphore. Sau đó, tWaitTask sẽ đợi ở trạng thái sẵn sàng cho đến khi Task có độ ưu tiên cao hơn tSignalTask thự c hiện lời gọi khóa hoặc delay chính nó.  tSignalTask tạo ra semaphore và tWaitTask nhận semaphore cho đến khi biến đếm semaphore là 0, ở thời điểm này tWaitTask tiếp tục đợi tSignalTask phát ra một semaphore. 1.3.4.3 Đồng bộ hóa trong chia sẻ tài nguyên hệ thống

Hình 1.21 : Sử dụng semaphore để đồng bộ hóa chia sẻ tài nguyên.  Vùng tài nguyên chia sẻ có thể là một vùng nhớ, một cấu trúc dữ liệu hoặc một thiết bị I/O , các thiết bị này được chia sẽ giữa 1 hay nhiều Task với những luồng thực thi đồng thời. Một semaphore có thể được sử dụng để “nối tiếp hóa” ( serialize) truy cập đến tài nguyên dùng chung này.  Trong trường hợp này, binary semaphore được khởi tạo ban đầu ở trạng thái sẵn sàng và được dùng để bảo vệ vùng tài nguyên chia sẻ này. Page 23

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Để truy cập đến tài nguyên chía sẻ này Task 1 và Task 2 cần phải nhận binary semaphore trước khi đọc hoặc ghi từ vùng tài nguyên dùng chung này.  Một trong những nguy hiểm của thiết kế này là bất kì task nào củng có thể tạo ra binary semaphore một cách ngẫu nhiên. Nếu như 2 Task cùng nhận được semaphore và đọc ghi đến vùng nhớ tại cùng một thời điểm, sẽ dẫn đến những ứng xử không chính xác của hệ thống.  Để chắc chắn điều này không xãy ra, chúng ta nên sử dụng mutex semaphore. Bởi vì một Mutex hỗ trợ khái niệm về quyền sở hữu, nó đảm bảo rằng chỉ duy nhất 1 task có thể nhận được semaphore thành công. 1.3.4.4 Đồng bộ hóa trong chia sẽ đa tài nguyên hệ thống

Hình 1.22: Sử dụng Counting semaphore để đồng bộ đa tài nguyên  Dùng cho trường hợp những tài nguyên tương đương nhau được sử dụng. Một counting semaphore có biến đếm được đặt là số tài nguyên tương đương dùng chung. Khi 2 Tasks đầu tiền yêu cầu semaphore thành công thì task thứ 3 phải đợi cho đến khi một trong 2 task đó giai phóng semaphore bị chiếm.  Khi dùng Binary semaphore có thể dẫn đến vấn đề nếu như 1 task nào đó giải phóng semaphore ma thực sự nó không yêu cầu, nếu đoạn code đơn giản thì điều này sẽ không là vấn đề gì nhưng nếu đoạn code khá phức tạp với nhiều Task cùng truy cập tài nguyên, mutex semaphore nên được sử dụng để bảo vệ thiết kế của ứng dụng.

Page 24

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

1.4 VẤN ĐỀ QUẢN LÝ QUEUE: 1.4.1 Định nghĩa Queue:

Hình 1.23 : Queue

1.4.2

 Là một máy giao tiếp dữ liệu giữa các Task. Một message Queue là một đối tượng tương tự như Buffer ( bộ nhớ đệm) thông qua Task hoặc ISR để gửi và nhận dữ “tin nhắn” (message) để giao tiếp và đồng bộ dữ liệu. Nó giữ tạm thời tin nhắn từ bên gửi ( sender) cho đến khi bên nhận được định trước ( intended receiver) sẵn sàng đọc dữ liệu.  Khi một message Queue được tạo ra lần đầu tiên, nó đượck gán đến một khối quản lý Queue( Queue control Block( QCB)), tên message Queue, ID duy nhất, bộ nhớ đệm ( buffer), chiều dài Queue, độ dài tôi đa mỗi tin nhắn, và môt hay nhiều danh sách các task đang chờ.  Một Message Queue có 2 danh sách các task đang chờ có liên quan. Một danh sách các task chờ nhận dữ liệu bao gồm các Task đang chờ khi Queue rỗng( không có dữ liệu). Danh sách các task đang chờ gửi gồm những task đang chở trong khi Queue đang đầy ( full) dữ liệu. Các trạng thái của Queue:

Hình 1.24: Trạng thái Của Queue Page 25

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Khi một Message Queue được tạo lần đầu tiên, Queue sẽ ở trạng thái rỗng  Nếu một Task cố gắng nhận nhận messages từ message queue trong khi queue đang rỗng , task sẽ bị khóa và được lưu lại trong danh sách các task đang chờ.  Nếu như một task khác gửi một message đến message queue, message này sẽ được chuyển trực tiếp đên Task bị khóa . Task bị khóa đó sẽ được xóa khỏi danh sách các task đang chờ và chuyển sang trạng thái sẵn sàng thực thi hoặc là đang thực thi.  Nuế như một task nào đó gửi một message đến cùng một message queue nhưng không có task nào chờ nhận trong danh sách các task chờ thì message queue sẽ trở nên không còn rỗng nữa.  Khi có thêm những message đến queue thì queue sẽ dần dần được lấp đầy và dẫn đến không còn không gian rỗi để nhận message nữa. Lúc này nếu như có một message nào khác gửi đến nữa thì sẽ không thành công trừ khi có một Task yêu cầu nhận dữ liệu từ Queue, vì nó sẽ giải phóng một thành phần của Queue.  Trong hiện thực một số Kernel, khi Task cố gắng gửi dữ liệu đi mà queue bị đầy thì hàm gửi đi sẽ trả về mã lỗi ( error code) cho Task đó. Một số Kernel khác lạu cho phép Task bị khóa và chuyển đến danh sách các task chờ gửi, danh sách này tách biệt với danh sách Task chờ nhận. 1.4.3

Các điều khiển liên qua đên Message Queue: 1.4.3.1 Tạo một Queue:  Khởi tạo các tham số: chiều dài queue, kích thước tối đa mỗi message, thứ tự chờ.. 1.4.3.2 Xóa một Queue:  Tự động mở khóa các task đang ở trạng thái chờ 1.4.3.3 Gửi message:

Hình 1.25: Gửi message đến Queue Page 26

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

 Khi gửi message, Kernel sẽ đưa điền vào message queue theo thứ tự từ “đầu đến cuối” ( head to tail) trong FIFO  Các kiểu gửi message:  Không khóa ( noneblocking) từ task hoặc ISRs Bên gửi sẽ không bị khóa nếu như Queue đầy mà sẽ trả về error code. Là cách duy nhất dùng cho việc gửi message từ ISRs vì ISRs không thể khóa được.  Khóa với thời gian timeout ( chỉ dành cho Task) Ngược lại so với None blocking  Khóa vĩnh viễn ( chỉ dùng cho Task).

Hình 1.26: Ứng xử với Task chờ Messsage

1.4.4

1.4.3.4 Nhận message:  Quá trình này diển ra tương tự như quá trinh gửi nhưng trình tự sẽ ngược lại.  Kiểu nhận message: None blocking Blocking Blocking vĩnh viễn.  Kiều đọc dữ liệu tử Queue: Đọc với tái cấu trúc dữ liệu Đọc nhưng không tái cấu trúc lại dữ liệu. 1.4.3.5 Đọc thông tin một Queue:  Có thể lấy các thông tin liên quan đến Queue  Có thể đọc được danh sách các Task đang trạng thái chờ. Sử dụng Message Queue:  Dữ liệu một chiều, không khóa giữa gửi và nhận

Page 27

Chương 1: Hệ điều hành thời gian thực RTOS

GVHD: ThS. Huỳnh Văn Kiểm SVTH: Lê Văn Mùi

Hình 1.27 : Queue dùng cho dữ liệu 1 chiều  Dữ liệu một chiều và có khóa ( interblock)

Hình 1.28 : dùng Queue và semaphore cho dữ liệu 1 chiều có khóa.  Dữ liệu 2 chiều:

Hình 1.29: Queue cho dữ liệu 2 chiều.

Page 28