[ RTOS ] 05. ThreadX의 Mutex

Mutexes

In addition to semaphores, ThreadX also provides a mutex object. A mutex is basically a binary semaphore, which means that only one thread can own a mutex at a time. In addition, the same thread may perform a successful mutex get operation on an owned mutex multiple times, 4,294,967,295 to be exact. There are two operations on the mutex object, namely tx_mutex_get and tx_mutex_put. The get operation obtains a mutex not owned by another thread, while the put operation releases a previously obtained mutex. In order for a thread to release a mutex, the number of put operations must equal the number of prior get operations.

Each mutex is a public resource. ThreadX places no constraints on how mutexes are used.

ThreadX mutexes are used solely for mutual exclusion. Unlike counting semaphores, mutexes have no use as a method for event notification.

세마포어 외에도 ThreadX는 뮤텍스 객체도 제공합니다. 뮤텍스는 기본적으로 이진 세마포어입니다. 즉, 한 번에 하나의 스레드 만 뮤텍스를 소유 할 수 있습니다. 또한 동일한 스레드가 소유 된 뮤텍스에서 성공적인 뮤텍스 가져 오기 작업을 여러 번 수행 할 수 있습니다 (정확히 4,294,967,295). 뮤텍스 객체에는 tx_mutex_get과 tx_mutex_put의 두 가지 작업이 있습니다. get 작업은 다른 스레드가 소유하지 않은 뮤텍스를 가져 오는 반면, 넣기 작업은 이전에 얻은 뮤텍스를 해제합니다. 스레드가 뮤텍스를 해제하려면 넣기 작업의 수가 이전 가져 오기 작업의 수와 같아야합니다.

각 뮤텍스는 공용 리소스입니다. ThreadX는 뮤텍스가 사용되는 방법에 제한을 두지 않습니다.

ThreadX 뮤텍스는 상호 배제에만 사용됩니다. 세마포를 세는 것과 달리 뮤텍스는 이벤트 알림을위한 방법으로 사용되지 않습니다.

• Mutex Mutual Exclusion

Similar to the discussion in the counting semaphore section, mutual exclusion pertains to controlling the access of threads to certain application areas (also called critical sections or application resources). When available, a ThreadX mutex will have an ownership count of 0. Once the mutex is obtained by a thread, the ownership count is incremented once for every get operation performed on the mutex and decremented for every put operation.

세마포어 계산 섹션의 논의와 유사하게 상호 배제는 특정 애플리케이션 영역 (중요 섹션 또는 애플리케이션 리소스라고도 함)에 대한 스레드 액세스를 제어하는 것과 관련이 있습니다. 사용 가능한 경우 ThreadX 뮤텍스의 소유권 개수는 0입니다. 스레드가 뮤텍스를 획득하면 소유권 개수는 뮤텍스에서 수행되는 모든 가져 오기 작업에 대해 한 번씩 증가하고 모든 넣기 작업에 대해 감소합니다.

• Creating Mutexes

ThreadX mutexes are created either during initialization or during run-time by application threads. The initial condition of a mutex is always “available.” Mutex creation is also where the determination is made as to whether or not the mutex implements priority inheritance.

ThreadX 뮤텍스는 초기화 중에 또는 애플리케이션 스레드에 의해 런타임 중에 생성됩니다. 뮤텍스의 초기 조건은 항상 "사용 가능"입니다. 뮤텍스 생성은 뮤텍스가 우선 순위 상속을 구현하는지 여부를 결정하는 곳이기도합니다.

• Thread Suspension

Application threads can suspend while attempting to perform a get operation on a mutex already owned by another thread.

Once the same number of put operations are performed by the owning thread, the suspended thread’s get operation is performed, giving it ownership of the mutex, and the thread is resumed. If multiple threads are suspended on the same mutex, they are resumed in the same order they were suspended (FIFO).

However, priority resumption is done automatically if the mutex priority inheritance was selected during creation. In addition, priority resumption is also possible if the application calls tx_mutex_prioritize prior to the mutex put call that lifts thread suspension. The mutex prioritize service places the highest priority thread at the front of the suspension list, while leaving all other suspended threads in the same FIFO order.

다른 스레드가 이미 소유 한 뮤텍스에 대해 가져 오기 작업을 수행하는 동안 응용 프로그램 스레드가 일시 중지 될 수 있습니다.

소유 스레드가 동일한 수의 넣기 작업을 수행하면 일시 중단 된 스레드의 가져 오기 작업이 수행되어 뮤텍스의 소유권을 부여하고 스레드가 재개됩니다. 여러 스레드가 동일한 뮤텍스에서 일시 중단 된 경우 일시 중단 된 동일한 순서 (FIFO)로 다시 시작됩니다.

그러나 생성 중에 뮤텍스 우선 순위 상속을 선택한 경우 우선 순위 재개가 자동으로 수행됩니다. 또한 스레드 중단을 해제하는 뮤텍스 풋 호출 이전에 애플리케이션이 tx_mutex_prioritize를 호출하는 경우에도 우선 순위 재개가 가능합니다. 뮤텍스 우선 순위 지정 서비스는 가장 높은 우선 순위 스레드를 일시 중단 목록의 맨 앞에 배치하고 다른 모든 일시 중단 스레드는 동일한 FIFO 순서로 둡니다.

• Mutex Control Block TX_MUTEX

The characteristics of each mutex are found in its control block. It contains interesting information such as the current mutex ownership count along with the pointer of the thread that owns the mutex.

This structure is defined in the tx_api.h file. Mutex control blocks can be located anywhere in memory, but it is most common to make the control block a global structure by defining it outside the scope of any function.

각 뮤텍스의 특성은 제어 블록에서 찾을 수 있습니다. 여기에는 뮤텍스를 소유 한 스레드의 포인터와 함께 현재 뮤텍스 소유권 수와 같은 흥미로운 정보가 포함되어 있습니다.

이 구조는 tx_api.h 파일에 정의되어 있습니다. Mutex 제어 블록은 메모리의 어느 곳에 나 위치 할 수 있지만 제어 블록을 모든 기능의 범위 밖에서 정의하여 글로벌 구조로 만드는 것이 가장 일반적입니다.

• Deadly Embrace

One of the most interesting and dangerous pitfalls associated with mutex ownership is the deadly embrace. A deadly embrace, or deadlock, is a condition where two or more threads are suspended indefinitely while attempting to get a mutex already owned by the other threads. The discussion of deadly embrace and its remedies found in the previous semaphore discussion is completely valid for the mutex object as well.

뮤텍스 소유권과 관련된 가장 흥미롭고 위험한 함정 중 하나는 치명적인 포용입니다. 치명적인 포괄 또는 교착 상태는 다른 스레드가 이미 소유 한 뮤텍스를 가져 오려고 시도하는 동안 두 개 이상의 스레드가 무기한 일시 중단되는 조건입니다. 이전 세마포어 논의에서 발견 된 치명적인 포용과 그 해결책에 대한 논의는 뮤텍스 객체에도 완전히 유효합니다.

• Priority Inversion

As mentioned previously, a major pitfall associated with mutual exclusion is priority inversion. This topic is discussed more fully in “Thread Priority Pitfalls” on page 62.

The basic problem results from a situation where a lower-priority thread has a semaphore that a higherpriority thread needs. This in itself is normal. However, threads with priorities in between them may cause the priority inversion to last a nondeterministic amount of time. Unlike semaphores discussed previously, the ThreadX mutex object has optional priority inheritance. The basic idea behind priority inheritance is that a lower priority thread has its priority raised temporarily to the priority of a high priority thread that wants the same mutex owned by the lower priority thread.

When the lower priority thread releases the mutex, its original priority is then restored and the higher priority thread is given ownership of the mutex. This feature eliminates undeterministic priority inversion by bounding the amount of inversion to the time the lower priority thread holds the mutex. Of course, the techniques discussed earlier in this chapter to handle undeterministic priority inversion are also valid with mutexes as well.

앞서 언급했듯이 상호 배제와 관련된 주요 함정은 우선 순위 반전입니다. 이 주제는 62 페이지의 "스레드 우선 순위 함정"에서 자세히 설명합니다.

기본적인 문제는 우선 순위가 낮은 스레드가 높은 우선 순위 스레드가 필요로하는 세마포어를 갖는 상황에서 발생합니다. 이것은 그 자체로 정상입니다. 그러나 그 사이에 우선 순위가있는 스레드는 우선 순위 반전이 비 결정적 시간 동안 지속되도록 할 수 있습니다. 이전에 논의 된 세마포와 달리 ThreadX 뮤텍스 개체에는 선택적 우선 순위 상속이 있습니다.

우선 순위 상속의 기본 아이디어는 우선 순위가 낮은 스레드가 우선 순위가 낮은 스레드가 소유 한 동일한 뮤텍스를 원하는 높은 우선 순위 스레드의 우선 순위로 일시적으로 우선 순위가 높아진다는 것입니다.

우선 순위가 낮은 스레드가 뮤텍스를 해제하면 원래 우선 순위가 복원되고 우선 순위가 높은 스레드에 뮤텍스의 소유권이 부여됩니다. 이 기능은 우선 순위가 낮은 스레드가 뮤텍스를 보유하는 시간으로 반전 양을 제한하여 비 결정적 우선 순위 반전을 제거합니다. 물론,이 장의 앞부분에서 비 결정적 우선 순위 반전을 처리하기 위해 논의한 기술은 뮤텍스에서도 유효합니다.