Книга: Real-Time Concepts for Embedded Systems
6.4.4 Single Shared-Resource-Access Synchronization
6.4.4 Single Shared-Resource-Access Synchronization
One of the more common uses of semaphores is to provide for mutually exclusive access to a shared resource. A shared resource might be a memory location, a data structure, or an I/O device-essentially anything that might have to be shared between two or more concurrent threads of execution. A semaphore can be used to serialize access to a shared resource, as shown in Figure 6.8.
![6.4.4 Single Shared-Resource-Access Synchronization](https://img-lib.wm-help.net/4015369950/pic_38.jpg)
Figure 6.8: Single shared-resource-access synchronization.
In this scenario, a binary semaphore is initially created in the available state (value = 1) and is used to protect the shared resource. To access the shared resource, task 1 or 2 needs to first successfully acquire the binary semaphore before reading from or writing to the shared resource. The pseudo code for both tAccessTask 1 and 2 is similar to Listing 6.4.
Listing 6.4: Pseudo code for tasks accessing a shared resource.
tAccessTask () {
:
Acquire binary semaphore token
Read or write to shared resource
Release binary semaphore token
:
}
This code serializes the access to the shared resource. If tAccessTask 1 executes first, it makes a request to acquire the semaphore and is successful because the semaphore is available. Having acquired the semaphore, this task is granted access to the shared resource and can read and write to it.
Meanwhile, the higher priority tAccessTask 2 wakes up and runs due to a timeout or some external event. It tries to access the same semaphore but is blocked because tAccessTask 1 currently has access to it. After tAccessTask 1 releases the semaphore, tAccessTask 2 is unblocked and starts to execute.
One of the dangers to this design is that any task can accidentally release the binary semaphore, even one that never acquired the semaphore in the first place. If this issue were to happen in this scenario, both tAccessTask 1 and tAccessTask 2 could end up acquiring the semaphore and reading and writing to the shared resource at the same time, which would lead to incorrect program behavior.
To ensure that this problem does not happen, use a mutex semaphore instead. Because a mutex supports the concept of ownership, it ensures that only the task that successfully acquired (locked) the mutex can release (unlock) it.
- Практическая работа 53. Запуск Access. Работа с объектами базы данных
- Shared Cache file
- Appendix E. Other resources and links
- Configure Access Control
- Запуск Access. Открытие учебной базы данных Борей
- 7.5.1. Файлы .htaccess
- Основы интерфейса Access 2007
- Листинг 10.2. Пример конфигурационного файла ftpaccess
- 15.4 Resource Synchronization Methods
- Глава 7 Разработка баз данных в программе Access
- Урок 7.1. Знакомство с программой Access
- Access 2007 как реляционная система управления базами данных