source: doc/theses/thierry_delisle_PhD/thesis/glossary.tex

Last change on this file was b0ceb72, checked in by Thierry Delisle <tdelisle@…>, 3 months ago

Merged peter's changes to the glossary

  • Property mode set to 100644
File size: 6.9 KB
Line 
1\makeglossaries
2
3% ----------------------------------
4% Acronyms
5\newacronym{api}{API}{Application Programming Interface}
6\newacronym{fifo}{FIFO}{First-In, First-Out}
7\newacronym{io}{I/O}{Input and Output}
8\newacronym{numa}{NUMA}{Non-Uniform Memory Access}
9\newacronym{prng}{PRNG}{Pseudo Random Number Generator}
10\newacronym{raii}{RAII}{Resource Acquisition Is Initialization}
11\newacronym{tls}{TLS}{Thread Local Storage}
12
13% ----------------------------------
14% Definitions
15
16\longnewglossaryentry{at}
17{name={Thread},text={thread}}
18{
19A thread is an independent sequential execution path through a program. Each thread is scheduled for execution separately and independently from other threads. Systems offer one or more concrete implementations of this concept, \eg \gls{kthrd}, \gls{job}, task. However, most of the concepts of scheduling are independent of the particular implementations of the thread representation. For this reason, this document uses the term \gls{at} to mean any of these representation that meets the general definition.
20
21\textit{Synonyms : Tasks, Jobs, Blocks.}
22}
23
24\longnewglossaryentry{proc}
25{name={Processor},text={processor}}
26{
27Entity that executes a \gls{at}, \ie the resource being scheduled by the scheduler. In kernel-level threading, \ats are kernel threads and \procs are the \glspl{hthrd} on which the kernel threads are scheduled. In user-level threading and thread pools, \procs are kernel threads.
28
29\textit{Synonyms : Server, Worker.}
30}
31
32\longnewglossaryentry{rQ}
33{name={Ready Queue}, text={ready-queue}}
34{
35Data structure holding \ats that are ready to \glslink{atrun}{run}. Often a \glsxtrshort{fifo} queue for fairness, but can take many different forms, \eg binary tree and priority queue are also common.
36}
37
38\longnewglossaryentry{uthrding}
39{name={User-Level Threading},text={user-level threading}}
40{
41Threading model where a scheduler runs in users space and maps threads managed and created inside the user-space onto \glspl{kthrd}.
42
43\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
44}
45
46\longnewglossaryentry{rmr}
47{name={Remote Memory Reference},text={remote memory reference}}
48{
49A memory reference to an address not in the current \gls{hthrd}'s cache is a remote reference. Memory references that \emph{are} in the current \gls{hthrd}'s cache is a \newterm{local} memory reference. For example, a cache line that must be updated from the any cache on another socket, or from RAM in a \glsxtrshort{numa} context.
50}
51
52% ----------------------------------
53
54\longnewglossaryentry{hthrd}
55{name={Hardware Threading},text={hardware thread}}
56{
57Threads representing the underlying hardware, \eg a CPU core or hyper-thread, if the hardware supports multiple threads of execution per core. The number of hardware threads present is fixed on any given computer.
58
59\textit{Synonyms : Core, Hyper-Thread, Processing Unit, CPU.}
60}
61
62\longnewglossaryentry{kthrd}
63{name={Kernel-Level Thread},text={kernel-level thread}}
64{
65Threads created and managed inside kernel space. Each kernel thread has its own stack and its own thread of execution. Kernel-level threads are owned, managed and scheduled by the underlying operating system.
66
67\textit{Synonyms : OS threads, Hardware threads, Physical threads.}
68}
69
70\longnewglossaryentry{fiber}
71{name={Fiber},text={fiber}}
72{
73Fibers are non-preemptive user-level threads. They share most of the characteristics of user-level threads except that they cannot be preempted by another fiber.
74
75\textit{Synonyms : Tasks.}
76}
77
78\longnewglossaryentry{job}
79{name={Job},text={job}}
80{
81Unit of work, often sent to a thread pool or worker pool to be executed. Has neither its own stack nor its own thread of execution.
82
83\textit{Synonyms : Tasks.}
84}
85
86\longnewglossaryentry{pool}
87{name={Thread Pool},text={thread-pool}}
88{
89Group of homogeneous threads that loop executing units of works. Often executing \glspl{jobs}.
90
91\textit{Synonyms : Executor.}
92}
93
94\longnewglossaryentry{preemption}
95{name={Preemption},text={preemption}}
96{
97Involuntary context switch imposed on threads at a given rate.
98
99\textit{Synonyms : None.}
100}
101
102\longnewglossaryentry{atsched}
103{name={Scheduling a \gls{at}}}
104{
105Scheduling a \at refers to notifying the scheduler that a \at is ready to run. When representing the scheduler as a queue of \ats, scheduling is the act of pushing a \at onto the end of the queue. This operation does not necessarily mean the \at is guaranteed CPU time (\gls{atrun}), \eg if the program terminates abruptly, scheduled \glspl{at} never run.
106
107\textit{Synonyms : Unparking.}
108}
109
110\longnewglossaryentry{atrun}
111{name={Running a \gls{at}}}
112{
113Running a \at refers to allocating CPU time to a \at that is ready to run. When representing the scheduler as a queue of \ats, running is the act of popping a \at from the front of the queue and putting it onto a \gls{proc}. The \gls{at} can then accomplish some or all of the work it is programmed to do.
114
115\textit{Synonyms : None.}
116}
117
118\longnewglossaryentry{atmig}
119{name={\Glspl{at} Migration}}
120{
121Migration refers to the idea of an \gls{at} running on a different \proc than the last time it was run. It is generally preferable to minimize migration as it incurs cost but any load balancing among \proc requires some amount of migration.
122
123\textit{Synonyms : None.}
124}
125
126\longnewglossaryentry{atpass}
127{name={Overtaking \gls{at}}}
128{
129When representing the scheduler as a queue of \glspl{at}, overtaking is the act breaking the FIFO-ness of the queue by moving a \gls{at} in front of some other \gls{at} when it arrived after. This remains true for schedulers that do not use a FIFO queue, when the order in which the \glspl{at} are \glslink{atsched}{scheduled} and \glslink{atrun}{run} in a different order. A \gls{at} is said to \emph{overtake} another if it is run \emph{before} but was \emph{scheduled} after the other \gls{at}.
130
131\textit{Synonyms : None.}
132}
133
134\longnewglossaryentry{atblock}
135{name={\Gls{at} Blocking}}
136{
137\Gls{at} blocking means taking a running \at off a CPU. Unless no other \at is ready, this action is immediately followed by running another \at.
138
139\textit{Synonyms : Parking.}
140}
141
142\longnewglossaryentry{atcomplet}
143{name={Running to completion}}
144{
145Running to completion refers to the entire sequence of : being scheduled, running and blocking, for a given \at.
146
147See also \gls{atsched}, \gls{atrun}, \gls{atblock}
148
149\textit{Synonyms : None.}
150}
151
152\longnewglossaryentry{load}
153{name={System Load},text={load}}
154{
155The system load refers to the rate at which \glspl{at} are \glslink{atsched}{scheduled} versus the rate at which they are \glslink{atrun}{run}. When \glspl{at} are being scheduled faster than they are run, the system is considered \emph{overloaded}. When \glspl{at} are being run faster than they are scheduled, the system is considered \emph{underloaded}. Correspondingly, if both rates are equal, the system is considered \emph{loaded}. Note the system is considered loaded only if the rate at which \glspl{at} are scheduled/run is non-zero, otherwise the system is empty, \ie it has no load.
156
157\textit{Synonyms : CPU Load, System Load.}
158}
159
Note: See TracBrowser for help on using the repository browser.