Changeset 6a6544d
- Timestamp:
- Jul 25, 2022, 11:47:32 AM (2 years ago)
- Branches:
- ADT, ast-experimental, master, pthread-emulation, qualifiedEnum
- Children:
- 970fa54
- Parents:
- 1988572
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/thierry_delisle_PhD/thesis/text/practice.tex
r1988572 r6a6544d 97 97 \end{figure} 98 98 99 \section{Idle-Sleep} 99 \section{Idle-Sleep}\label{idlesleep} 100 100 While manual resizing of \procs is expected to be rare, the number of \ats can vary significantly over an application's lifetime, which means there are times when there are too few or too many \procs. 101 101 For this work, it is the programer's responsibility to manually create \procs, so if there are too few \procs, the application must address this issue. … … 113 113 However, this third challenge is outside the scope of this thesis because developing a general heuristic is complex enough to justify its own work. 114 114 Therefore, the \CFA scheduler simply follows the ``Race-to-Idle''~\cite{Albers12} approach where a sleeping \proc is woken any time a \at becomes ready and \procs go to idle sleep anytime they run out of work. 115 An interesting sub-part of this heuristic is what to do with bursts of \ats that become ready. 116 Since waking up a sleeping \proc can have notable latency, it is possible multiple \ats become ready while a single \proc is waking up. 117 This facts begs the question, if many \procs are available, how many should be woken? 118 If the ready \ats will run longer than the wake-up latency, waking one \proc per \at will offer maximum parallelisation. 119 If the ready \ats will run for a short very short time, waking many \procs may be wasteful. 120 As mentioned, a heuristic to handle these complex cases is outside the scope of this thesis, the behaviour of the scheduler in this particular case is left unspecified. 115 121 116 122 \section{Sleeping} … … 199 205 Notifiers that obtained a @NULL@ in the exchange simply move on, knowing that another notifier is already waking a \proc. 200 206 This behaviour is equivalent to having multiple notifier write to the @fd@ since reads consume all previous writes. 207 Note that with and without this atomic pointer, bursts of notification can lead to an unspecified number of \procs being woken up, depending on how the arrival notification compares witht the latency of \procs waking up. 208 As mentioned in section~\ref{idlesleep}, there is no optimal approach to handle these bursts. 209 It is therefore difficult to justify the cost of any extra synchronization here. 201 210 202 211 \begin{figure}[t]
Note: See TracChangeset
for help on using the changeset viewer.