Unblocked Dsp

Multiprocessor semaphore

SEMAPHORE Multiprocessor

Summary
=============================================
Shared memory semaphores are basic tools for interprocessor synchronization. Although
restrictions self-imposed design can often reduce synchronization requirements, traffic lights offer great flexibility to designers of multiprocessor systems. The application presented here illustrates some issues fundamental competition with multiple processors and demonstrates the tremendous value of a multitasking OS like DSP / BIOS.
There are many variations on this theme are possible. Obviously, we can modify the traffic light to handle multiple tasks in a processor or task in more than two processors. And because our operation pending notification handles interruptions and the task of awakening, "we can implement any scheduling policy that makes sense for the generalized versions.

SEMAPHORE Multiprocessor
==============================================
Multiprocessor architectures are becoming ubiquitous. DSP is widely used in agreements with several thick at the edge of the network, on-chip systems often include DSP cores to accelerate the math force. Although DSP / BIOS provides a standard, efficient, powerful API for applications with a single processor, we sometimes encounter situations where synchronization mechanisms interprocessor would be useful. Here we will take a look at multiprocessor mutual exclusion and we will talk about new method to implement interprocessor traffic lights using DSP-BIOS.
Many multi-processor DSP systems are designed to share a group of physical memory in the sense that each processor sees the memory as directly addressable – a DSP share a memory region with a DSP processor or other host.
A common architecture uses a large RAM memory region single-port shared by all devices, including the host. Although the arbitration issues complicate the hardware design. A second architecture uses RAM dual ported between processors. The disadvantage is the relatively high cost and low storage capacity of these devices – DPRAM big banks face are rarely practical. But in transport applications using segmented data or small data sets where small amounts of DPRAM are sufficient, this method is very useful. DPRAM is relatively fast, designer-friendly and, unlike FIFOs can store shared data structures used for interprocessor communication.
We have recall the memory when used to share. When the processors have cache on the chip or system uses a write ad, software designers must pay attention a shared variable consistency. According to the processor, developers can disable cache, use cache bypass, or discharge to ensure cache a shared location is in a proper state. The cache control API global IT Chip Support Library, for example, provides an ideal tool for management of the cache subsystem. Solutions to problems of delay writing emails are system specific.
Our discussion here assumes Two commonly used processors shared memory buffer to pass data or to operate together in a dataset. In any case, one or more tasks on processors need to know the status of the buffer before accessing it, and possibly to lock the buffer while in use. As in the case of single-processor multitasking is requires a mutual exclusion mechanism to prevent inappropriate repurchase the share. Let's start with a quick review of the mutual exclusion to better understand the issues multiprocessor.
Shared management of resources is a fundamental challenge of multitasking. A task (or thread, or process) requires ability to execute sequences of instructions without interference so atomically can manipulate the shared data. These sequences, known as critical sections, are bracketed by entry and exit protocols that satisfy four properties – mutual exclusion, absence of deadlock, the absence of unnecessary delays and possible input (without hunger). Our objective here is mutually exclusive – the remaining properties are detailed in any number of textbooks and will be satisfied by our light with multiple processors.
Relative to a shared resource, mutual exclusion requires that only one task at a time running on a critical section. section entry critical and output protocols use mechanisms such as flags respondents (often called simple twist locks or locks) or more abstract entities such as blocking traffic lights. simple locks may be used to build protection mechanisms more complex.
B-Semaphore
The semaphore is an abstraction system-level used for synchronization between processes. It has two atomic operations, wait (P) and signal (V), used to manipulate a non-negative integer within the data structure of traffic lights. The wait operation controls the value of the integer and either positive or decrease if the task blocks call. The operation unlock signal is a task waiting at the light or increase the traffic light if no tasks are waiting. A binary semaphore, with limited value to 0 and 1, can be used effectively an application to protect critical sections.
A semaphore can be implemented by multi-placement structure of data in shared memory and the use of RTOS services in each processor to handle the lock. Before outlining an application, let's look at two aspects of traffic lights cause complications in a multiprocessor environment. One is the low-level mutex to protect data shared within a traffic light and the other is to wake notification when a semaphore is released.
low-level mutual exclusion
At its core, a semaphore has a count variable and data elements, possibly others must be handled atomically. Simple system calls using mutual exclusion mechanisms to protect critical sections short where you can access the structure semaphore. This prevents the correct results of the simultaneous modification of shared data traffic lights.
In an environment with a single processor, masking break is a popular technique used to ensure that sequential operations occur without interference. Interrupts are disabled at the entrance to a section criticism and re-enable the output. In a multiprocessor situation, however, this is not an option. Even if a processor could disable interrupts other (rarely the case), the second processor would run an active thread may inadvertently violate the requirements of mutual exclusion.
A second technique using an atomic test and set (or similar) instruction to manipulate a variable. This variable could be the count of the semaphore itself or simply block dedicated to care in critical sections that access the data of traffic lights. Either way, one specialized instruction guarantees atomic read-modify-write in a multitasking environment. Although this seems a simple solution, test and system has disadvantages in uniprocessor and multiprocessor scenarios. One drawback is the dependency of instructions machine. These vary between processors, offer only a small number of atomic operations and sometimes not available. A second problem is blocking bus. If multiple processors share a common bus does not support blockades during the trial-and-set, the processors can interleave accesses to a shared variable bus level during the execution apparently atomic test and set instructions. A third problem is the testing behavior and adjustment in the memory systems Multi-port RAM. Even if all buses can be locked, simultaneous test and configure different ports sequences could result in overlapping accesses.
Consider now two approaches are very useful in situations of shared memory. One is based on simple atomic hardware locks and the other is a general purpose software solution algorithm known as Peterson.
Flags Hardware
In shared memory systems, the hardware-assisted mutual exclusion can be implemented with special flags found little in the multi-port rams. DPRAM logic prevents the overlapping of these flags repurchase hardware, forcing to maintain the correct state during simultaneous access. And because the standard-issue processors using read / write instructions to manipulate the flags testing and special instructions, as no adjustment is necessary. But this is still a limited solution – software engineers are often shared memory systems lacking this feature. So let's take one more step to reach a general purpose method independent of the hardware.
Peterson's algorithm
Peterson's algorithm, published in 1981, provides an elegant software solution to the problem of n-process critical section and has two distinct advantages over spin locks testing and adjustment. One is that the atomic test-and-set is not required – The algorithm eliminates the need for special instructions and blocking buses. The other is the possible entry – a task waiting to access a critical section will not starve in a weak right (typical) programming environment. While Peterson's algorithm seems deceptively simple, is the culmination of many attempts by researchers to solve the problem of critical section.
The following pseudo-code shows entry and exit protocols used in the implementation of two processes of mutual exclusion. Note that Peterson added a second "turn variable" – this prevents incorrect results from race conditions and also ensures that every task of waiting finally enters the critical section.
Listing 1: Algorithm Peterson
initialization
P2_wants_entry P1_wants_entry = FALSE
turn = P1
P1 task
P1_wants_entry = TRUE / * * lock assembly /
turn P2 = / * grant to turn to other tasks * /
while (turn == P2_wants_entry and P2) / * * lock hold buzz /

critical section / * Run * critical section /

P1_wants_entry = False / * release lock * /
P2 task / * same logic * P1 /
= TRUE P2_wants_entry
turn = P1
while (turn == P1_wants_entry and P1)
critical section
P2_wants_entry = FALSE
It is easy to imagine situations where more than two processes try to enter their critical sections simultaneously. Peterson's algorithm can be generalized for n processes and are used to enforce mutual exclusion between more than two tasks. And the solutions-n other processes, such as the bakery algorithm, are available in textbooks of computer science. Our discussion here is limited to the case of two single process for clarity and brevity. Pseudo-code for the n-process algorithm can be found in Peterson's web-site Electric Arena.
Lock mechanism
Now that we have a tool for low-level mutex to safely manipulate the shared data at a light note other key ingredient of traffic lights, lock. Assuming that each processor executes DSP / BIOS or other multitasking operating system, we develop our operation looks services already available in each individual processor. DSP / BIOS provides a flexible form of traffic lights (SEM) we use in our application.
When the owner of a single processor semaphore is released with a call to the signaling system, the local developer is immediately notified of the case of the signal and can unlock a task waiting at the light. By contrast, a multiprocessor traffic light means that the owner and the applicant can reside on different processors. Because core Remote has no implicit knowledge of the calls of the signal to a local kernel, the remote node requires timely notification of events in the signal local. Our solution uses interprocessor interrupts to notify other processors of local activity with the participation of a shared semaphore.
Light application
This implementation of a binary semaphore multiprocessor (MBS) assumes that the hardware supports interprocessor interrupts and that a task will seek to acquire a semaphore, while another task on the same processor you have. This latter restriction simplifies the example and can be easily removed with a job additional design.
The wait operation
MBS_wait is invoked to acquire a semaphore shared memory. If the semaphore is available, which decreases MBS_wait and continues. If the semaphore is already owned, the blocks of the applicant within MBS_wait tasks until a statement of notification of termination makes it ready for run. Once the interruption occurs and higher priority tasks have renounced the CPU, the task waiting at the traffic lights in MBS_wait wakes and loops back to try. Note that the task is not immediately assume ownership when provided. Because of a remote control task may re-acquire the traffic lights by the time the applicant awake MBS_wait ties to compete for the traffic lights again.
When MBS_wait determines that a traffic light is not available, a flag is set request notice in the semaphore for shared data structure to indicate that the processor must be interrupted when the light is released elsewhere in the system. For avoid a race condition known as the problem of loss of clock, MBS_wait atomically tests the lights and set the prompt notification if the light is not available.
Code for the wait operation is divided into two distinct parts. MBS_wait contains the lock code and is called by an application. MBS_interrupt runs in response to the notice of termination and the posts of a local signal to the task waiting at the light. This is very similar a device driver model, where the top of a suspended driver a pending task of I / O and service breaks down party wakes up.
The operation of the signal
MBS_signal releases a semaphore to increase their value and the publication of an interrupt to a processor that requested notification release. This makes MBS_interrupt to execute on the processor is locked away in a task in the light. Note that this varies slightly from the operation signal with a single processor has been described above in the light is increased only if no tasks are blocked.

Pseudo-code
Now we have a notion of shared architecture traffic light, take a look at pseudo-code that describes the wait and signal operations. Note that this example applies to a version with two processors on a single task at a time in each processor attempts to acquire the semaphore. General implementations maintenance and distribution of processors more traffic lights between multiple tasks on each processor can be implemented with N-process algorithm by Peterson and modification operations MBS.
Note that critical sections, enforced by the algorithm of Peterson (Peterson Peterson input and output) are very short sequences of instructions to manipulate the data structure semaphore. The details of Peterson's algorithm are not shown – these are implicit in Peterson input output operations. The blockade of the variables used turn into Peterson's algorithm are different elements of semaphore access data in critical sections.
Critical sections are prefaced with DSP / BIOS TSK_disable calls to prevent task switching. A task switch in a critical section could cause another processor to spin indefinitely in Peterson's income if you try acquire the same semaphore. Critical sections must be implemented as soon as possible.
Also note that the example omits error checking return values and wait times. The pseudo-code is intended to highlight the topics of discussion rather than provide a detailed implementation template.

MBS_wait () (
success = false / * local variable is not part of semaphore * /
while (success == false) (/ * Repeat semaphore * attempted acquisition /
TSK_disable () / * Prevents the DSP / BIOS task switch * /
Peterson entry / * entry protocol Peterson * /
/ * Critical section begins * /
if (Sem_value> 1) (
sem_value sem_value = – 1
success = TRUE
)
else (
notification_request = TRUE
)
Peterson exit / end critical section * /
TSK_enable () / * re-enable DSP / BIOS scheduler * /
if (success == FALSE) (/ * local variable * result shows /
SEM_pend () / * sleep with DSP / BIOS semaphore * /
)
)
)
MBS_interrrupt (
SEM_post () / * local wake-up signal with DSP / BIOS * /
)
MBS_post () (/ * release semaphore * /
TSK_disable ()
Peterson login

/ Top of critical section * /

sem_value sem_value = 1 / * increase the semaphore * /
if (Notification_request == TRUE) (/ * notify a remote task? * /
send a notice of termination / * Yes – send an interrupt * /
)
Peterson exit / end critical section * /
TSK_enable ()
)
==============================================

About the Author

Dr.Wael AlBayaydh has has been working in information technology for several years, concentrating on areas such as operating system, networking, electronic commerce, Internet services, LDAP and Web servers. AlBayaydh has authored a number of articles for some publications, and he presents his own papers at industry conferences. He can be reached at wr_y@hotmail.com