source: doc/theses/thierry_delisle_PhD/comp_II/glossary.tex @ 9317419

ADTast-experimental
Last change on this file since 9317419 was df75fe97, checked in by Thierry Delisle <tdelisle@…>, 5 years ago

Committing first draft of my comp-II

  • Property mode set to 100644
File size: 5.3 KB
RevLine 
[df75fe97]1\makeglossaries
2
3\longnewglossaryentry{hthrd}
4{name={hardware thread}}
5{
6Threads representing the underlying hardware directly.
7
8\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
9}
10
11\longnewglossaryentry{uthrd}
12{name={user-level thread}}
13{
14Threads created and managed inside user-space. Each thread has its own stack and its own thread of execution. User-level threads are invisible to the underlying operating system.
15
16\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.}
17}
18
19\longnewglossaryentry{kthrd}
20{name={kernel-level thread}}
21{
22Threads created and managed inside kernel-space. Each thread has its own stack and its own thread of execution. Kernel-level threads are owned, managed and scheduled by the underlying operating system.
23
24\textit{Synonyms : OS threads, Hardware threads, Physical threads.}
25}
26
27\longnewglossaryentry{fiber}
28{name={fiber}}
29{
30Fibers are non-preemptive user-level threads. They share most of the caracteristics of user-level threads except that they cannot be preempted by another fiber.
31
32\textit{Synonyms : Tasks.}
33}
34
35\longnewglossaryentry{job}
36{name={job}}
37{
38Unit 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.
39
40\textit{Synonyms : Tasks.}
41}
42
43\longnewglossaryentry{pool}
44{name={thread-pool}}
45{
46Group of homogeneuous threads that loop executing units of works after another.
47
48\textit{Synonyms : }
49}
50
51\longnewglossaryentry{preemption}
52{name={preemption}}
53{
54Involuntary context switch imposed on threads at a given rate.
55
56\textit{Synonyms : None.}
57}
58
59\longnewglossaryentry{proc}
60{name={virtual processor}}
61{
62
63}
64
65\longnewglossaryentry{Q}
66{name={work-queue}}
67{
68
69}
70
71\longnewglossaryentry{at}
72{name={fred}}
73{
74Abstract object representing an unit of work. Systems will offer one or more concrete implementations of this concept (\eg \gls{kthrd}, \gls{job}), however, most of the concept of schedulings are independent of the particular implementations of the work representation. For this reason, this document use the term \Gls{at} to mean any representation and not one in particular.
75}
76
77\longnewglossaryentry{atsched}
78{name={Scheduling a \gls{at}}}
79{
80Scheduling an \gls{at} refers to the act of notifying the scheduler that a task is ready to be ran. When representing the scheduler as a queue of tasks, scheduling is the act of pushing a task onto the end of the queue. This doesn't necesserily means the task will ever be allocated CPU time (\gls{atrun}), for example, if the system terminates abruptly, scheduled \glspl{at} will probably never run.
81
82\textit{Synonyms : None.}
83}
84
85\longnewglossaryentry{atrun}
86{name={Running a \gls{at}}}
87{
88Running an \gls{at} refers to the act of allocating CPU time to a task that is ready to run. When representing the scheduler as a queue of tasks, running is the act of poping a task from the front of the queue and putting it onto a \gls{proc}. The \gls{at} can than accomplish some or all of the work it is programmed to do.
89
90\textit{Synonyms : None.}
91}
92
93\longnewglossaryentry{atmig}
94{name={migration of \gls{at}}}
95{
96Migration refers to the idea of an \gls{at} running on a different worker/processor than the last time it was run. It is generally preferable to minimise migration as it incurs cost but any load balancing among workers requires some amount of migration.
97
98\textit{Synonyms : None.}
99}
100
101\longnewglossaryentry{atpass}
102{name={overtaking \gls{at}}}
103{
104When 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}.
105
106\textit{Synonyms : None.}
107}
108
109\longnewglossaryentry{atblock}
110{name={Blocking an \gls{at}}}
111{
112Blocking an abstract task refers to the act of taking a task that us running on a CPU off the CPU. Unless no other task is ready, this action is generally immediately followed by running an other task.
113
114\textit{Synonyms : None.}
115}
116
117\longnewglossaryentry{atcomplet}
118{name={Running to completion}}
119{
120Running to completion refers to the entire sequence of : being scheduled, running and blocking, for a given task.
121
122See also \gls{atsched}, \gls{atrun}, \gls{atblock}
123
124\textit{Synonyms : None.}
125}
126
127\longnewglossaryentry{load}
128{name={System Load}}
129{
130The load is 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}. Conrrespondingly, if both rates are equal, the system is considered \emph{loaded}. Note that the system is considered loaded only of the rate at which \glspl{at} are scheduled/run is non-zero, otherwise the system is empty, it has no load.
131}
132
133
134\newacronym{tls}{TLS}{Thread Local Storage}
135\newacronym{api}{API}{Application Program Interface}
136\newacronym{raii}{RAII}{Resource Acquisition Is Initialization}
137\newacronym{numa}{NUMA}{Non-Uniform Memory Access}
Note: See TracBrowser for help on using the repository browser.