ENGG4420 CHAPTER 2 LECTURE 6

Transcription

1 CHAPTER 2 ucosiii Page 1 ENGG4420 CHAPTER 2 LECTURE 6 October :03 PM SEMAPHORE INTERNALS OS_SEM data type defined in os.h Semaphore services are enabled at compile time by setting the configuration constant OS_CFG_SEM_EN to 1 in os_cfg.h Note, that uc/os III doesn't make a distinguish between counting and binary semaphores when initial value is 1 then is treated as binary.

2 CHAPTER 2 ucosiii Page 2 PRIORITY INVERSIONS Priority inversion occurs only when using a prioritybased preemptive kernel. Example below uses 3 tasks: Task H (high priority), Task M (medium priority), and Task L (low priority). (1) L is executing while H and M are both waiting for an event. (2) L acquires a semaphore to access a resource (3) L performs operations on the acquired resource (4) Event for H happens and L is suspended (5) WHAT HAPPENED?? During (9) the priority of Task H has been reduced to that of Task L since it waited for the resource that Task L owned this is called unbounded priority inversion. SOLUTION??

3 CHAPTER 2 ucosiii Page 3 MUTUAL EXCLUSION SEMAPHORE MUTEX MUTEX is a special type of binary semaphore that eliminates the unbounded priority inversion (6) Task H attempts to get the mutex from Task L. Given that Task L owns the resource, uc/os III raises the priority of Task L to H so that Task L will finish with the resource without being preempted by Task M. (8) Task L finishes with the resource. uc/os III will reduce the priority of Task L from H back to L. Next, it will give the mutex to Task H. Note that there is no priority inversion but only resource sharing.

4 CHAPTER 2 ucosiii Page 4 MUTEX INTERNALS uc/os III implements full priority inheritance and therefore if a higher priority requests a resource, the priority of the owner task will be raised to the priority of the new requestor. A mutex is a kernel object defined by the OS_MUTEX data type. ISR are not allowed to use mutexes There are a number of functions that are performed on mutexes:

5 CHAPTER 2 ucosiii Page 5 USAGE OF MUTEXES A mutex must be created before it can be used by an application A task waits on a mutex before it can access the resource

6 CHAPTER 2 ucosiii Page 6 SHOULD YOU USE A SEMAPHORE INSTEAD OF A MUTEX A semaphore can be used instead of a mutex if none of the tasks competing for the shared resource have deadlines to be satisfied. If there are deadlines to be met, a mutex should be used to access the shared resource to eliminate the unbounded priority inversion.

7 CHAPTER 2 ucosiii Page 7 DEADLOCK (OR DEADLY EMBRACE) A deadlock is a situation where two tasks are each unknowingly waiting for resources held by the other. Assume T1 has exclusive access to resource R1 and T2 has exclusive access to R2 as shown below: T1 executes before T2; T2 has a higher priority T1 is deadlock at (9) waiting for M2 T2 is deadlock at (7) waiting for M1

8 CHAPTER 2 ucosiii Page 8 TECHNIQUES USED TO AVOID DEADLOCKS 1) Acquire all resources before proceeding, and in the same order, 2) Always acquire resources in the same order 3) Use timeouts on pend calls this method doesn't really solve the deadlock, it just breaks it. ACQUIRE ALL RESOURCES BEFORE PROCESSING

9 CHAPTER 2 ucosiii Page 9 ALWAYS ACQUIRE SEMAPHORES IN THE SAME ORDER In this method you need to make sure that the mutexes are acquired in the same order for both task.

10 CHAPTER 2 ucosiii Page 10 SYNCHRONIZATION How tasks can synchronize their activities with Interrupt Service Routines (ISRs), or other tasks? Servicing interrupting devices from task level is preferred, since it reduces the amount of time that interrupts are disabled and the code is easier to debug. There are two main methods for synchronization in uc/os III: 1) COUNTING SEMAPHORES, AND 2) EVENT FLAGS. COUNTING SEMAPHORES semaphores are best used to synchronize an ISR to a task, or synchronize a task with another task as shown below: The N value next to the flag indicates that the semaphore can accumulate events or credits. An ISR or a task can post multiple times to a semaphore, and the semaphore will remember how many times it was posted.

11 CHAPTER 2 ucosiii Page 11 OPERATIONS PERFORMED ON SEMAPHORES For uc/os III, the maximum value of a semaphore is determined by the data type OS_SEM_CTR (see os_type.h), which is changeable. Along with the semaphore's value, uc/os III keeps track of tasks waiting for the semaphore to be signaled.

12 CHAPTER 2 ucosiii Page 12 UNILATERAL RENDEZ VOUS When no data needs to be exchanged we can use a semaphore in a unilateral rendez vous way to synchronize a task with an ISR or other task. Unilateral rendez vous is used when a task initiates an I/O operation and waits (i.e., calll OSSemPend()). When the I/O operation is complete, an ISR or other task signals the semaphore. Task HP synchronizes with an ISR. (4) HP task pends on a semaphore for an event (6) the event has taken place

13 CHAPTER 2 ucosiii Page 13 PENDING ON A SEMAPHORE The task doesn't need to know about the details of what happens behind the scenes, it just calls OSSemPend() that will return when the event occurs.

14 CHAPTER 2 ucosiii Page 14 CREDIT TRACKING A semaphore remembers how many times it was signaled (or posted to). When the task becomes the highest priority readyto run task, it will execute without blocking as many times as there are signals counted this is called credit tracking. (3) an event meant for a lower priority task occurs which preempts the task (assuming interrupts are enabled). The ISR executes and posts to the semaphore. (17) the task waiting for the semaphore event is switched to and will know that the ISR occurred two times.

15 CHAPTER 2 ucosiii Page 15 MULTIPLE TASKS WAITING ON A SEMAPHORE We can have multiple tasks waiting for the same semaphore, each with its own timeout: uc/os III makes the highest priority task waiting on a semaphore ready to run. However, uc/os III supports broadcasting and can signal to all the tasks at once by specifying OS_OPT_POST_ALL as an option when calling OSSemPost(). Broadcasting is a common technique used to synchronize multiple tasks but there could be situations when we perform a synchronization to a task that might not waiting for a semaphore. This problem can be solved by combining semaphores and event flags.

16 CHAPTER 2 ucosiii Page 16 SEMAPHORE INTERNALS FOR SYNCHRONZATION A semaphore is a kernel object as defined by the OS_SEM data type. The services provided for the semaphores are implemented in the file os_sem.c Semaphores must be created before they can be used by the application. (6) a semaphore contains a time stamp, which is used to indicate the last time the semaphore was signaled (or posted to) uc/os III assumes the presence of a freerunning counter that allows the application to make time measurements.

17 USAGE OF SEMAPHORES FOR SYNCHRONIZATION CHAPTER 2 ucosiii Page 17

18 CHAPTER 2 ucosiii Page 18 TASKS WAITING FOR SEMAPHORE When posting with OS_OPT_POST_1, you post to only the highest priority task. If there are multiple tasks at the same priority, only one of them will be made ready to run. When posting with OS_OPT_POST_ALL, all tasks waiting for the semaphore will be made ready. Also, the posting can "add" the option. OS_OPT_POST_NO_SCHED (additive option) to indicate that the scheduler is not to be called at the end of OSSemPost().

19 CHAPTER 2 ucosiii Page 19 TASK SEMAPHORES In uc/os III each task has its own built in semaphore this feature simplifies code and is efficient. You can use this feature if you know which task to signal when the event occurs. SEMAPHORE BUILT INTO A TASK

20 CHAPTER 2 ucosiii Page 20 PENDING ON A TASK SEMAPHORE When a task is created, it automatically creates an internal semaphore with an initial value of zero. POSTING A TASK SEMAPHORE An ISR or a task can signal a task by calling OSTaskSemPost();

21 CHAPTER 2 ucosiii Page 21 BILATERAL RENDEZ VOUS WITH TASK SEMAPHORES Two tasks can synchronize their activities by using two task semaphores in a bilateral way. Both tasks must synchronized with one another before proceeding. A bilateral rendez vous cannot be performed between a task and an ISR because an ISR cannot wait on a semaphore.

22 CODE FOR BILATERAL RENDEZ VOUS CHAPTER 2 ucosiii Page 22

23 CHAPTER 2 ucosiii Page 23 EVENT FLAGS "Event flag group" is a kernel object of type OS_FLAG_GRP and consists of a series of bits. Object used when a task needs to synchronize with the occurrence of multiple events. We can have disjunctive (logical OR) synchronization when any of the events have occurred. We can have conjunctive synchronization (logical AND), when all events have occurred. The application programmer can create an unlimited number of event flag groups. The flag services are enabled at compile time by setting the configuration constant OS_CFG_FLAG_EN to 1 in os_cfg.h. You need to create event flags prior to starting uc/os III, or by a startup task in your application.

24 CHAPTER 2 ucosiii Page 24 OPERATIONS TO PERFORM ON EVENT FLAGS EXAMPLE In an event flag group you can define that bit #0 indicates that a temperature sensor is too low, bit #1 may indicate a low battery voltage, bit #2 could indicate that a switch was pressed, etc. The code (task or ISR) that detects these conditions would set the appropriate event flag by calling OSFlagPost(). The task(s) that would respond to those conditions would call OSflagPend(). The operations of OR and AND can be made for bits to be set (1) or clear (0).

25 USING EVENT FLAGS CHAPTER 2 ucosiii Page 25

26 CHAPTER 2 ucosiii Page 26 EVENT FLAGS APPLICATIONS 1) Used for status, a. Temperature has exceeded a certain value, an engine RPM is zero, there is fuel in the tank, etc. b. Status information cannot be consumed by the task waiting for the event. c. Status event flags are monitored by other task by using non blocking wait calls. 2) Used for transient events. a. Switch was pressed, an object was detected by a motion sensor, etc. b. The task waiting for these events will normally block and consume the event.

27 CHAPTER 2 ucosiii Page 27 EVENT FLAGS INTERNALS Event flag groups must be created before they can be used by an application (4) initialize all the flags in the group to zero if the task or ISR signal events by setting bits and to 1 if the signal events are cleared.

28 CHAPTER 2 ucosiii Page 28 PENDING AND POSTING TO AN EVENT GROUP (1) OSFlagPost() returns the current value of the event flags in the event flag group after the post has been performed. (2) indicates which bits will be setting or clearing, (3) you can specify OS_OPT_POST_FLAG_SET or OS_OPT_POST_FLAG_CLR.

29 CHAPTER 2 ucosiii Page 29 SYNCHRONIZING MULTIPLE TASK RENDEZVOUS (1) each task that needs to synchronize at the rendez vous needs to set an event flag bit (and specify OS_OPT_POST_NO_SCHED). (2) the task needs to wait for the semaphore to be posted. (3) the task that will be broadcasting must wait for "all" of the event flags corresponding to each task to be set. (4) when all waiting task are ready, the task that will synchronize the waiting task issues a broadcast to the semaphore.