Only one task readied this task is responsible for ensuring integrity of critical region.All tasks readied with error condition.In terms of what happens to the waiting tasks, there are various models, but two doiminate: If a task terminates for any reason, the RTOS can detect if that task current owns a mutex and signal waiting tasks of this condition. The details of the Priority Inheritance Protocol and Priority Ceiling Protocol (a slight variant) will be covered in part 3 of this series. The low priority task can now run and unlock the mutex – at this point it is returned back to its original priority. The Basic Priority Inheritance Protocol enables a low-priority task to inherit a higher-priorities task’s priority if this higher-priority task becomes blocked waiting on a mutex currently owned by the low-priority task. With ownership this problem can be addressed using one of the following priority inheritance protocols: The concept of ownership enables mutex implementations to address the problems discussed in part 1:Īs already stated, ownership stops accidental release of a mutex as a check is made on the release and an error is raised if current task is not owner.ĭue to ownership, a mutex can support relocking of the same mutex by the owning task as long as it is released the same number of times. If the mutual exclusion object doesn’t have ownership then, irrelevant of what it is called, it is not a mutex.
If a task tries to unlock a mutex it hasn’t locked (thus doesn’t own) then an error condition is encountered and, most importantly, the mutex is not unlocked. Ownership is the simple concept that when a task locks (acquires) a mutex only it can unlock (release) it. The mutex is similar to the principles of the binary semaphore with one significant difference: the principle of ownership. In 1990 this was formalised by the IEEE as standard IEEE Std 1003.1 commonly known as POSIX. I have struggled to find it’s first clear definition, but the major use of the term mutex (another neologism based around MUTual EXclusion) appears to have been driven through the development of the common programming specification for UNIX based systems. To address the problems associated with semaphore, a new concept was developed during the late 1980’s. In this posting I aim to show how a different RTOS construct, the mutex, may overcome some, if not all, of these weaknesses.
#SEMAPHOR WITH OR WITHOUT EMAIL SERIES#
In Part 1 of this series we looked at the history of the binary and counting semaphore, and then went on to discuss some of the associated problem areas.
0 kommentar(er)
