Page Comparison

Include Page

	css.Resource ManagementRun-Time Statistics.css
	css.Resource ManagementRun-Time Statistics.css

Include Page

	css.webworks.css
	css.webworks.css

Anchor

	104989110927321049891
	1092732

Semaphores

...

Anchor

	10498921092733	1049892

A semaphore was originally a mechanical signaling mechanism. The railroad industry used the device to provide a form of mutual exclusion for railroads tracks shared by more than one train. In this form, the semaphore signaled trains by closing a set of mechanical arms to block a train from a section of track that was currently in use. When the track became available, the arm would swing up and the waiting train would then proceed. Anchor10498931049893 The notion of using a semaphore in software as a means of mutual exclusion was invented by the Dutch computer scientist Edgser Dijkstra in 1959. In computer software, a semaphore is a protocol mechanism offered by most multitasking kernels. Semaphores, originally used to control access to shared resources, but now they are used for synchronization as described in Chapter 14, “Synchronization” on page 251. However, it is useful to describe how semaphores can be used to share resources. The pitfalls of semaphores will be discussed in a later section. Anchor10498951049895 A semaphore was originally a “lock mechanism” and code acquired the key to this lock to continue execution. Acquiring the key means that the executing task has permission to enter the section of otherwise locked code. Entering a section of locked code causes the task to wait until the key becomes available. Anchor10782001078200 Typically, two types of semaphores exist: binary semaphores and counting semaphores. As its name implies, a binary semaphore can only take two values: 0 or 1. A counting semaphore allows for values between 0 and 255, 65,535, or 4,294,967,295, depending on whether the semaphore mechanism is implemented using 8, 16, or 32 bits, respectively. For µC/OS-III, the maximum value of a semaphore is determined by the data type OS_SEM_CTR (see os_type.h), which can be changed as needed. Along with the semaphore’s value, µC/OS-III also keeps track of tasks waiting for the semaphore’s availability. Anchor10498971049897 Only tasks are allowed to use semaphores when semaphores are used for sharing resources; ISRs are not allowed. Anchor10498981049898 A semaphore is a kernel object defined by the OS_SEM data type, which is defined by the structure os_sem (see os.h). The application can have any number of semaphores (limited only by the amount of RAM available). Anchor10498991049899 There are a number of operations the application is able to perform on semaphores, summarized in Table 13-2. In this chapter, only three functions used most often are discussed: OSSemCreate(), OSSemPend(), and OSSemPost(). Other functions are described in Appendix A, “µC/OS-III API Reference” on page 431. When semaphores are used for sharing resources, every semaphore function must be called from a task and never from an ISR. The same limitation does not apply when using semaphores for signaling, as described later in Chapter 13. Anchor10795861079586

...

1092733

.NamePtr

Anchor

	1064813
	1064813

This is a pointer to an ASCII string used to provide a name to the semaphore. The ASCII string can have any length as long as it is NUL terminated.

Anchor

	1064814
	1064814

.PendList.NbrEntries

Anchor

	1064815
	1064815

Each semaphore contains a wait list of tasks waiting for the semaphore to be signaled. The variable represents the number of entries in the wait list.

Anchor

	1064816
	1064816

.Ctr

Anchor

	1064817
	1064817

This variable represents the current count of the semaphore.

Anchor

	1064818
	1064818

.TS

Anchor

	1077627
	1077627

This variable contains the timestamp of when the semaphore was last signaled.

Versions Compared

Old Version 3

New Version 4

Key