Texas Instruments TMS320 DSP User Manual Page 17
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
2.2.2 Preemptive vs. Non-Preemptive Multitasking
2.2.3 Reentrancy
Threads and Reentrancy
Non-preemptive multitasking relies on each thread to voluntarily relinquish control to the operating system
before letting another thread execute. This is usually done by requiring threads to periodically call an
operating system function, say yield(), to allow another thread to take control of the CPU or by simply
requiring all threads to complete within a specified short period. In a non-preemptive multi-threading
environment, the amount of time a thread is allowed to run is determined by the thread, whereas in a
preemptive environment, the time is determined by the operating system and the entire set of tasks that
are ready to run.
Note that the difference between those two flavors of multi-threading can be a very big one; for example,
under a non-preemptive system, you can safely assume that no other thread executes while a particular
algorithm processes data using on-chip data memory. Under preemptive execution, this is not true; a
thread may be preempted while it is in the middle of processing. Thus, if your application relies on the
assumption that things do not change in the middle of processing some data, it might break under a
preemptive execution scheme.
Since preemptive systems are designed to preserve the state of a preempted thread and restore it when
its execution continues, threads can safely assume that most registers and all of the thread's data memory
remain unchanged. What would cause an application to fail? Any assumptions related to the maximum
amount of time that can elapse between any two instructions, the state of any global system resource
such as a data cache, or the state of a global variable accessed by multiple threads, can cause an
application to fail in a preemptive environment.
Non-preemptive environments incur less overhead and often result in higher performance systems; for
example, data caches are much more effective in non-preemptive systems since each thread can control
when preemption (and therefore, cache flushing) will occur.
On the other hand, non-preemptive environments require that either each thread complete within a
specified maximum amount of time, or explicitly relinquish control of the CPU to the framework (or
operating system) at some minimum periodic rate. By itself, this is not a problem since most DSP threads
are periodic with real-time deadlines. However, this minimum rate is a function of the other threads in the
system and, consequently, non-preemptive threads are not completely independent of one another; they
must be sensitive to the scheduling requirements of the other threads in the system. Thus, systems that
are by their nature multirate and multichannel often require preemption; otherwise, all of the algorithms
used would have to be rewritten whenever a new algorithm is added to the system.
If we want all algorithms to be framework-independent, we must either define a framework-neutral way for
algorithms to relinquish control, or assume that algorithms used in a non-preemptive environment always
complete in less than the required maximum scheduling latency time. Since we require documentation of
worst-case execution times, it is possible for system integrators to quickly determine if an algorithm will
cause a non-preemptive system to violate its scheduling latency requirements. Thus, the TMS320 DSP
Algorithm Standard does not define a framework-neutral "yield" operation for algorithms.
Since algorithms can be used in both preemptive and non-preemptive environments, it is important that all
algorithms be designed to support both. This means that algorithms should minimize the maximum time
that they can delay other algorithms in a non-preemptive system.
Reentrancy is the attribute of a program or routine that allows the same copy of the program or routine to
be used concurrently by two or more threads.
Reentrancy is an extremely valuable property for functions. In multichannel systems, for example, any
function that can be invoked as part of one channel's processing must be reentrant ; otherwise, that
function would not be usable for other channels. In single channel multirate systems, any function that
must be used at two different rates must be reentrant; for example, a general digital filter function used for
both echo cancellation and pre-emphasis for a vocoder. Unfortunately, it is not always easy to determine if
a function is reentrant.
SPRU352G – June 2005 – Revised February 2007 General Programming Guidelines 17
Submit Documentation Feedback
- User's Guide 1
- Submit Documentation Feedback 2
- Contents 3
- Read This First 7
- Related Documentation 8
- Text Conventions 8
- Overview 9
- 1.1 Scope of the Standard 10
- 1.1.1 Rules and Guidelines 11
- 1.3 Goals of the Standard 12
- 1.4 Intentional Omissions 12
- 1.5 System Architecture 13
- 1.5.1 Frameworks 13
- 1.5.2 Algorithms 14
- 1.5.3 Core Run-Time Support 14
- Chapter 2 15
- 2.1 Use of C Language 16
- 2.2 Threads and Reentrancy 16
- 2.2.1 Threads 16
- 2.2.3 Reentrancy 17
- 2.2.4 Example 18
- 2.3 Data Memory 19
- 2.3.1 Memory Spaces 20
- Data Memory 21
- 2.4 Program Memory 23
- 2.5 ROM-ability 23
- 2.6 Use of Peripherals 24
- Algorithm Component Model 25
- 3.1 Interfaces and Modules 26
- 3.1.1 External Identifiers 27
- 3.1.2 Naming Conventions 28
- 3.1.4 Module Instance Objects 28
- Interfaces and Modules 29
- 3.1.7 Module Configuration 30
- 3.1.8 Example Module 30
- 3.1.10 Interface Inheritance 32
- 3.1.11 Summary 32
- 3.2 Algorithms 33
- 3.3 Packaging 34
- 3.3.1 Object Code 34
- 3.3.2 Header Files 35
- 3.3.3 Debug Verses Release 35
- Packaging 36
- Chapter 4 37
- 4.1 Data Memory 38
- 4.1.1 Heap Memory 38
- 4.1.2 Stack Memory 39
- 4.2 Program Memory 40
- 4.3 Interrupt Latency 41
- 4.4 Execution Time 41
- 4.4.1 MIPS Is Not Enough 41
- 4.4.2 Execution Time Model 42
- Execution Time 43
- DSP-Specific Guidelines 45
- 5.1 CPU Register Types 46
- 5.2 Use of Floating Point 47
- 5.3.1 Endian Byte Ordering 47
- 5.3.2 Data Models 47
- 5.3.3 Program Model 47
- 5.3.4 Register Conventions 48
- 5.3.5 Status Register 48
- 5.3.6 Interrupt Latency 49
- 5.4.1 Data Models 49
- 5.4.2 Program Models 49
- 5.4.3 Register Conventions 51
- 5.4.4 Status Registers 51
- 5.4.5 Interrupt Latency 52
- 5.5.1 Stack Architecture 52
- 5.5.2 Data Models 52
- 5.5.3 Program Models 53
- 5.5.4 Relocatability 53
- 5.5.5 Register Conventions 54
- 5.5.6 Status Bits 55
- 5.6 TMS320C24xx Guidelines 57
- 5.6.1 General 57
- 5.6.2 Data Models 57
- 5.6.3 Program Models 57
- 5.6.4 Register Conventions 57
- 5.6.5 Status Registers 58
- 5.6.6 Interrupt Latency 58
- 5.7.1 Data Models 58
- 5.7.2 Program Models 59
- 5.7.3 Register Conventions 59
- 5.7.4 Status Registers 59
- 5.7.5 Interrupt Latency 60
- Use of the DMA Resource 61
- 6.1 Overview 62
- 6.2 Algorithm and Framework 62
- 6.4 Logical Channel 63
- 6.5 Data Transfer Properties 64
- 6.7 Abstract Interface 65
- 6.8 Resource Characterization 66
- 6.9 Runtime APIs 67
- 6.15.1 Non-Preemptive System 71
- 6.15.3 Preemptive System 72
- Rules and Guidelines 75
- A.1 General Rules 76
- A.3 DMA Rules 77
- A.4 General Guidelines 78
- A.5 DMA Guidelines 79
- Core Run-Time APIs 81
- Bibliography 83
- Glossary 85
- Glossary of Terms 86
© 2020, manymanuals.com. All rights reserved. | 1.928 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals