Using RTOS Semaphores - Part 3: exotic semaphores

Ralph Moore, Micro Digital, Inc.

November 23, 2014

Ralph Moore, Micro Digital, Inc.November 23, 2014

Part 1 and Part 2 of this three-part blog discussed resource and event semaphores. This time I will cover the more exotic semaphores: threshold, gate, and reader/writer. These are not commonly available, but they should be.

Threshold semaphore
A threshold semaphore is used to deal with events where thresholds are relevant. The threshold specifies the count at which the semaphore "fires" -- i.e. allows one task to proceed. Hence, a certain number of actions must complete before a waiting task is allowed to resume. When a semaphore fires, its count is reduced by the amount of the threshold. As with a multiple event semaphore, counts are not lost, when no task is waiting. Thus the count could get several thresholds ahead of the task that it controls. As this task catches up, the count is reduced one threshold, at a time.

The following is an example of using a threshold semaphore, st:



Gate semaphore
A gate semaphore is the inverse of a threshold semaphore: one signal causes all waiting tasks to be let loose -- it is similar to the proverbial corral gate vs. horses. Tasks are resumed in FIFO order. Thus, they will run in their order of waiting at each priority level. No count is recorded, so tasks that subsequently test the gate semaphore must wait for the next signal -- i.e. the corral gate has been closed. The following is an example of using a gate semaphore:



Assuming the tasks execute in the above order, t2a and t2b will be waiting at sg, when t2c runs. When t2c signals sg, both t2a and t2b run, then wait at sg again. A gate semaphore provides a convenient way to start multiple waiting tasks. In this example, that process repeats every five ticks.

Combined threshold & gate example
Threshold and gate semaphores work well together, as illustrated by the following example for message broadcasting. For reliable operation the broadcaster needs to know when all receivers have read the current message and it needs to notify all receivers when it has posted a new message. This is complicated if the sender does not know the identities of receivers nor even how many of them there are. Threshold and gate semaphores help solve these problems, as follows:




In this example, the initialization function creates gate (sg) and threshold (st) semaphores, a broadcast message exchange (xb), three receivers (t2r0, t2r1, and t2r2) and one sender (t2s). To simplify this example, the receivers share a main function, but generally that would not be the case. After being created and started, each receiver tests sg and waits on it for a signal. After being created and started, the broadcaster composes a message, sends it to the broadcast exchange, xb, then signals sg. This allows the receivers to receive the message, read it, then signal st that they are done. When the third receiver signals st, its threshold of 3 is reached and the broadcaster prepares another message and sends it.

Reader/writer semaphore
The reader/writer semaphore operates like a multiple event semaphore and a mutex combined. Briefly, readers are allowed only to read a resource, while writers may both read and write the resource. (Note: readers and writers are tasks.) Typically the resource is a section of memory, such as a control structure, but it could also be a file or a device. Any number of readers can access the resource, at once, but only one writer can access the resource, at once.

When a writer is waiting, no new writers or readers are allowed to start. They must wait in the writer queue or in the reader queue of the semaphore. When the last reader finishes, the first waiting writer gains sole access to the resource. When it finishes writing, it signals the semaphore and the next waiting writer is allowed sole access to the resource. When all writers are done, all waiting readers are immediately allowed to access the now updated resource; an internal counter is incremented for each reader granted access. Readers are expected to access the resource for only a short time, then signal that they are done. This decrements the internal semaphore counter. New readers are granted access as long as no writer is waiting.

I have not yet implemented this semaphore, because I am waiting to learn if anyone thinks they need it. Thus I can provide no example of how to use it.

To read Part 1, go to: Resource semaphores
To read Part 2, go to: Event semaphores

References:
1. SMX User’s Guide and Reference Manual

Ralph Moore, President of Micro Digital, graduated with a degree in physics from Caltech. He spent his early career in computer research. Then he moved into mainframe design in the 60's and became a consultant in the early 70's. He taught himself programming and became a microprocessor programmer. He founded Micro Digital in 1975, and many years of successful consulting led into architecting and developing the SMX kernel in 1987. For many years he managed the company’s business and sales, but in recent years he has been focused almost solely on v4.







< Previous
Page 1 of 2
Next >

Loading comments...