| 1 | \makeglossaries | 
|---|
| 2 |  | 
|---|
| 3 | \longnewglossaryentry{hthrd} | 
|---|
| 4 | {name={hardware thread}} | 
|---|
| 5 | { | 
|---|
| 6 | Threads 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 | { | 
|---|
| 14 | Threads 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 | { | 
|---|
| 22 | Threads 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 | { | 
|---|
| 30 | Fibers 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 | { | 
|---|
| 38 | Unit 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 | { | 
|---|
| 46 | Group of homogeneuous threads that loop executing units of works after another. | 
|---|
| 47 |  | 
|---|
| 48 | \textit{Synonyms : } | 
|---|
| 49 | } | 
|---|
| 50 |  | 
|---|
| 51 | \longnewglossaryentry{preemption} | 
|---|
| 52 | {name={preemption}} | 
|---|
| 53 | { | 
|---|
| 54 | Involuntary 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 | { | 
|---|
| 74 | Abstract 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 | { | 
|---|
| 80 | Scheduling 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 | { | 
|---|
| 88 | Running 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 | { | 
|---|
| 96 | Migration 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 | { | 
|---|
| 104 | When 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 | { | 
|---|
| 112 | Blocking 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 | { | 
|---|
| 120 | Running to completion refers to the entire sequence of : being scheduled, running and blocking, for a given task. | 
|---|
| 121 |  | 
|---|
| 122 | See also \gls{atsched}, \gls{atrun}, \gls{atblock} | 
|---|
| 123 |  | 
|---|
| 124 | \textit{Synonyms : None.} | 
|---|
| 125 | } | 
|---|
| 126 |  | 
|---|
| 127 | \longnewglossaryentry{load} | 
|---|
| 128 | {name={System Load}} | 
|---|
| 129 | { | 
|---|
| 130 | The 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} | 
|---|