🌱 Core 20. RTOS - Mutex

    Ở những Post trước mình đã giới thiệu về Binary Semaphore và Counting Semaphore, đó là những cơ chế đồng bộ task và quản lý tài nguyên trong RTOS. Đối với vấn đề Race Condition được nêu ra ở post trước, chúng ta có thể sử dụng giải pháp đó là Mutex. Vậy Mutex là gì? Mình sẽ cùng các bạn tìm hiểu dưới đây! 

    👉 Mutex là gì?

    Mutex - viết tắt của MUtial EXclution, tức là loại trừ lẫn nhau. Thực chất nó là một Flag - cờ, hay một Key - khóa, được sử dụng cho phép hoặc hạn chế quyền truy cập vào một tài nguyên - resource. 

    Nghe đến key thì có vẻ nó khá giống Binary Semaphore. Đúng như vậy, cơ chế Mutex hoạt động giống như Binary Semaphore, tại một thời diểm nó chỉ cho phép một task truy cập vào resource, và nó sẽ chặn tất cả các task khác truy cập vào resource này. 

    Cách sử dụng Mutex cũng khá đơn giản, nó hoạt động theo cơ chế acquire (yêu cầu) - release (nhả). Tức là một task sẽ yêu cầu Mutex khi cần sử dụng tài nguyên chung, và sau khi sử dụng xong thì nó sẽ nhả Mutex để cho task khác có thể thực hiện. Nếu Mutex đang được một task sử dụng thì những task khác sẽ phải chờ để nhận được Mutex.

     👉 Ví dụ sử dụng Mutex

    Chúng ta sẽ thử xem một ví dụ, chính là ví dụ sử dụng Mutex để giải quyết Bài toán Race Condition ở post trước.

    Ở bài toán này, task main và Systick_Handler sử dụng chung tài nguyên là thanh ghi GPIOB_ODR. 

    Ở đây có thể xảy ra Race Condition với việc mỗi câu lệnh C bằng 3 câu lệnh ASM, và việc ngắt Systick có thể xảy ra khi mà câu lệnh đảo LED PB3 chưa thực hiện xong là hoàn toàn có thể xảy ra (Xem post trước). 

     👉 Ở đây, chúng ta hãy thử dùng một Mutex để ngăn Race Condition xảy ra. Bằng cách ở mỗi task, ta sẽ cho task đó đợi Mutex free thì mới thực hiện truy cập thanh ghi GPIOB_ODR để đảo led. Task sở hữu Mutex sẽ thực hiện công việc của mình, sau đó mới nhả (release) Mutex cho các task khác.

    Ok, vậy bây giờ chương trình của chúng ta đã an toàn rồi, hiện tại không cần phải lo cho việc một câu lệnh nào đó chưa thực hiện xong mà câu lệnh khác có thể nhảy xen vào. 

    Thậm chí cả những task có ưu tiên cao hơn muốn thực thi thì cũng sẽ phải đợi Mutex free trước, vì cơ chế đổi mức ưu tiên trong lúc giữ Mutex. Tức là khi giữ Mutex, task sẽ tạm thời có mức ưu tiên cao nhất, nên không task nào có thể xen vào. Chỉ khi task nhả Mutex ra thì mức ưu tiên mới trở lại như ban đầu.

    👉 Mutex vs Binary Semaphore

    Có thể thấy Mutex và Binary Semaphore có cách hoạt động tương đối giống nhau, vậy tại sao lại phải tạo ra 2 cơ chế khác nhau? 

• Mutex hoạt động theo cơ chế Locking trong khi Binary Semaphore hoạt động theo cơ chế Signaling. Vì vậy, task có ưu tiên cao hơn hoàn toàn có thể giải phóng Binary Semaphore và chiếm quyền sử dụng tài nguyên. Trong khi đó, dù có ưu tiên cao hơn, nhưng task vẫn phải chờ Mutex thực hiện xong. 
• Binary Semaphore có thể đồng thời được sở hữu bởi nhiều thread trong khi Mutex thì chỉ được sở hữu bởi một thread duy nhất.
• Trên thực tế, Binary Semaphore sẽ thực hiện nhanh hơn Mutex vì các thread/process khác có thể giải phóng Semaphore, trong khi chỉ có thread/process mới có thể unlock Mutex. 
• Mutex thường được sử dụng trong trường hợp có một tài nguyên duy nhất, ví dụ như Race Condition ở trên. Trong khi Semaphore có thể sử dụng trong trường hợp có nhiều tài nguyên hơn.

>>>= Follow ngay =<<<

Để theo dõi những bài học miễn phí mới nhất nhé 😊

Chúc các bạn học tập tốt 😊