Changeset ea1bb94 for doc/theses
- Timestamp:
- Jul 11, 2023, 9:25:01 AM (18 months ago)
- Branches:
- master
- Children:
- 39e6309
- Parents:
- 614868b
- Location:
- doc/theses/colby_parsons_MMAth
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/colby_parsons_MMAth/local.bib
r614868b rea1bb94 196 196 year={2004} 197 197 } 198 199 @manual{IntelManual, 200 keywords = {Intel}, 201 title = {Intel 64 and IA-32 Architectures Software Developer’s Manual}, 202 version = {Version 080}, 203 organization= {Intel}, 204 month = March, 205 year = 2023, 206 } -
doc/theses/colby_parsons_MMAth/text/actors.tex
r614868b rea1bb94 752 752 The values swapped are never null pointers, so a null pointer can be used as an intermediate value during the swap. 753 753 \end{enumerate} 754 Figure~\ref{ c:swap} shows the \CFA pseudocode for the \gls{dcasw}.754 Figure~\ref{f:dcaswImpl} shows the \CFA pseudocode for the \gls{dcasw}. 755 755 In detail, a thief performs the following steps to swap two pointers: 756 756 \begin{enumerate}[start=0] … … 765 765 Since each worker owns a disjoint range of the queue array, it is impossible for @my_queue@ to be null. 766 766 Note, this algorithm is simplified due to each worker owning a disjoint range, allowing only the @vic_queue@ to be checked for null. 767 This was not listed as a special case of this algorithm, since this requirement can be avoided by modifying Step 1 of Figure~\ref{ c:swap} to also check @my_queue@ for null.767 This was not listed as a special case of this algorithm, since this requirement can be avoided by modifying Step 1 of Figure~\ref{f:dcaswImpl} to also check @my_queue@ for null. 768 768 Further discussion of this generalization is omitted since it is not needed for the presented application. 769 769 \item … … 811 811 \end{cfa} 812 812 \caption{DCASW Concurrent} 813 \label{ c:swap}813 \label{f:dcaswImpl} 814 814 \end{figure} 815 815 … … 817 817 \gls{dcasw} is correct in both the success and failure cases. 818 818 \end{theorem} 819 To verify sequential correctness, Figure~\ref{ s:swap} shows a simplified \gls{dcasw}.819 To verify sequential correctness, Figure~\ref{f:seqSwap} shows a simplified \gls{dcasw}. 820 820 Step 1 is missing in the sequential example since it only matters in the concurrent context. 821 821 By inspection, the sequential swap copies each pointer being swapped, and then the original values of each pointer are reset using the copy of the other pointer. … … 836 836 \end{cfa} 837 837 \caption{DCASW Sequential} 838 \label{ s:swap}838 \label{f:seqSwap} 839 839 \end{figure} 840 840 … … 895 895 First it is important to state that a thief will not attempt to steal from themselves. 896 896 As such, the victim here is not also a thief. 897 Stepping through the code in \ref{ c:swap}, for all thieves steps 0-1 succeed since the victim is not stealing and will have no queue pointers set to be @0p@.897 Stepping through the code in \ref{f:dcaswImpl}, for all thieves steps 0-1 succeed since the victim is not stealing and will have no queue pointers set to be @0p@. 898 898 Similarly for all thieves step 2 will succeed since no one is stealing from any of the thieves. 899 899 In step 3 the first thief to @CAS@ will win the race and successfully swap the queue pointer. … … 991 991 992 992 The longest-victim heuristic maintains a timestamp per executor thread that is updated every time a worker attempts to steal work. 993 The timestamps are generated using @rdtsc@~\cite{ } and are stored in a shared array, with one index per worker.993 The timestamps are generated using @rdtsc@~\cite{IntelManual} and are stored in a shared array, with one index per worker. 994 994 Thieves then attempt to steal from the worker with the oldest timestamp. 995 995 The intuition behind this heuristic is that the slowest worker will receive help via work stealing until it becomes a thief, which indicates that it has caught up to the pace of the rest of the workers. 996 This heuristic means that if two thieves look to steal at the same time, they likely attempt to steal from the same victim. 996 This heuristic should ideally result in lowered latency for message sends to victim workers that are overloaded with work. 997 However, a side-effect of this heuristic is that if two thieves look to steal at the same time, they likely attempt to steal from the same victim. 997 998 This approach consequently does increase the chance at contention among thieves; 998 999 however, given that workers have multiple queues, often in the tens or hundreds of queues, it is rare for two thieves to attempt stealing from the same queue.
Note: See TracChangeset
for help on using the changeset viewer.