Thông tin tài liệu:
Real-Time Embedded Multithreading Using ThreadX and MIPS- P6:Although the history of embedded systems is relatively short, 1 the advances andsuccesses of this fi eld have been profound. Embedded systems are found in a vast array ofapplications such as consumer electronics, “ smart ” devices, communication equipment,automobiles, desktop computers, and medical equipment.
Nội dung trích xuất từ tài liệu:
Real-Time Embedded Multithreading Using ThreadX and MIPS- P6 CHAPTE R 8 Mutual Exclusion Challenges and Considerations 8.1 Introduction On many occasions, we need to guarantee that a thread has exclusive access to a shared resource or to a critical section. However, several threads may need to obtain these items, so we need to synchronize their behavior to ensure that exclusive access can be provided. In this chapter, we consider the properties of the mutex, which is designed solely to provide mutual exclusion protection by avoiding conflict between threads and preventing unwanted interactions between threads. A mutex is a public resource that can be owned by, at most, one thread at any point in time. Furthermore, a thread (and only that same thread) can repeatedly1 obtain the same mutex 232–1 times, to be exact. However, that same thread (and only that thread) must give up that mutex the same number of times before the mutex becomes available again. 8.2 Protecting a Critical Section A critical section is a code segment in which instructions must be executed in sequence without interruption. The mutex helps in achieving this goal. Consider Figure 8.1, which shows a code segment that is a critical section. To enter this critical section, a thread must first obtain ownership of a certain mutex that protects the critical section. Thus, when the thread is ready to begin executing this code segment, it first attempts to acquire that 1 Some writers describe this type of mutex as a recursive mutex because of the same-thread, multiple-ownership capability. However, we will not use that terminology here. w w w.ne w nespress.comPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 100 Chapter 8 Code segment Mutex Thread Figure 8.1: Mutex protecting a critical section Mutex 1 Resource 1 Thread Mutex 2 Resource 2 Figure 8.2: Mutexes providing exclusive access to multiple shared resources mutex. After the thread has acquired the mutex, it executes the code segment, and then relinquishes the mutex. 8.3 Providing Exclusive Access to Shared Resources A mutex can provide exclusive access to one shared resource in the same manner that it can protect a critical section. That is, a thread must first obtain the mutex before it can access the shared resource. However, if a thread must have exclusive access to two (or more) shared resources at the same time, then it must protect each shared resource with a separate mutex. In this case, the thread must first obtain a particular mutex for each of the shared resources before continuing. Figure 8.2 illustrates this process. When the thread is ready to access these resources, it first gets the two mutexes that protect these resources. After the thread has acquired both mutexes, it accesses the shared resources, and then relinquishes both mutexes after it has finished with these resources. w ww. n e w n e s p r e s s .c o mPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Mutual Exclusion Challenges and Considerations 101 Field Description tx_mutex_id Control block ID tx_mutex_name Pointer to mutex name tx_mutex_ownership_count Mutex ownership count *tx_mutex_owner Mutex ownership pointer tx_mutex_inherit Priority inheritance flag tx_mutex_original_priority Original priority of owning thread tx_mutex_original_threshold Original preemption-threshold of owning thread *tx_mutex_suspension_list Pointer to suspension list tx_mutex_suspended_count Suspension list count *tx_mutex_created_next Pointer to the next mutex in the created list *tx_mutex_created_previous Pointer to the previous mutex in the created list Figure 8.3: Mutex Control Block ...