Changeset 04c31f4 for doc/theses/colby_parsons_MMAth/text
- Timestamp:
- Jul 10, 2023, 5:10:11 PM (21 months ago)
- Branches:
- master
- Children:
- 0aa77e6
- Parents:
- c3f7dd9
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
TabularUnified doc/theses/colby_parsons_MMAth/text/actors.tex ¶
rc3f7dd9 r04c31f4 740 740 In this case, there is a race between loading the register and performing the swap (discussed shortly). 741 741 742 Hence, a novel swap is constructed, called \gls{das}, special cased in two ways: 742 Either a true memory/memory swap instruction or a \gls{dcas} would provide the ability to atomically swap two memory locations, but unfortunately neither of these instructions are supported on the architectures used in this work, and would require simulation. 743 Hence, a novel swap for this use case is constructed, called \gls{dcasw}. 744 The \gls{dcasw} is effectively a \gls{dcas} special cased in two ways: 743 745 \begin{enumerate} 744 746 \item 745 747 It works on two separate memory locations, and hence, is logically the same as. 746 748 \begin{cfa} 747 bool D AS( T * assn1, T * assn2) {748 return DCAS( assn1, assn2, *assn1, *assn2, *assn2, *assn1);749 bool DCASW( T * dst, T * src ) { 750 return DCAS( dest, src, *dest, *src, *src, *dest ); 749 751 } 750 752 \end{cfa} 751 753 \item 752 The values swapped are never null pointers, so a null pointer can be used as an intermediate value sduring the swap.754 The values swapped are never null pointers, so a null pointer can be used as an intermediate value during the swap. 753 755 \end{enumerate} 754 Figure~\ref{c:swap} shows the \CFA pseudocode for the \gls{d as}.756 Figure~\ref{c:swap} shows the \CFA pseudocode for the \gls{dcasw}. 755 757 In detail, a thief performs the following steps to swap two pointers: 756 758 \begin{enumerate}[start=0] … … 764 766 At no other point is a queue pointer set to null. 765 767 Since each worker owns a disjoint range of the queue array, it is impossible for @my_queue@ to be null. 768 Note, this algorithm is simplified due to each worker owning a disjoint range, allowing only the @vic_queue@ to be checked for null. 769 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. 770 Further discussion of this generalization is omitted since it is not needed for the presented application. 766 771 \item 767 772 attempts to atomically set the thief's queue pointer to null. … … 807 812 } 808 813 \end{cfa} 809 \caption{D ASConcurrent}814 \caption{DCASW Concurrent} 810 815 \label{c:swap} 811 816 \end{figure} 812 817 813 818 \begin{theorem} 814 \gls{d as} is correct in both the success and failure cases.819 \gls{dcasw} is correct in both the success and failure cases. 815 820 \end{theorem} 816 To verify sequential correctness, Figure~\ref{s:swap} shows a simplified \gls{d as}.821 To verify sequential correctness, Figure~\ref{s:swap} shows a simplified \gls{dcasw}. 817 822 Step 1 is missing in the sequential example since it only matters in the concurrent context. 818 823 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. … … 832 837 } 833 838 \end{cfa} 834 \caption{D ASSequential}839 \caption{DCASW Sequential} 835 840 \label{s:swap} 836 841 \end{figure} 837 842 838 To verify concurrent correctness, it is necessary to show \gls{d as} is wait-free, \ie all thieves fail or succeed in swapping the queues in a finite number of steps.843 To verify concurrent correctness, it is necessary to show \gls{dcasw} is wait-free, \ie all thieves fail or succeed in swapping the queues in a finite number of steps. 839 844 This property is straightforward, because there are no locks or looping. 840 845 As well, there is no retry mechanism in the case of a failed swap, since a failed swap either means the work is already stolen or that work is stolen from the thief. … … 864 869 Once a thief atomically sets their queue pointer to be @0p@ in step 2, the invariant guarantees that that pointer does not change. 865 870 In the success case of step 3, it is known the value of the victim's queue-pointer, which is not overwritten, must be @vic_queue@ due to the use of @CAS@. 866 Given that pointers all have unique memory locations, this first write of the successful swap is correct since it can only occur when the pointer has not changed.871 Given that the pointers all have unique memory locations, this first write of the successful swap is correct since it can only occur when the pointer has not changed. 867 872 By the invariant, the write back in the successful case is correct since no other worker can write to the @0p@ pointer. 868 873 In the failed case of step 3, the outcome is correct in steps 1 and 2 since no writes have occurred so the program state is unchanged. 869 874 Therefore, the program state is safely restored to the state it had prior to the @0p@ write in step 2, because the invariant makes the write back to the @0p@ pointer safe. 875 Note that the assumption of the pointers having unique memory locations prevents the ABA problem in this usage of \gls{dcasw}, but it is not needed for correctness of the general \gls{dcasw} operation. 870 876 871 877 \begin{comment} … … 987 993 988 994 The longest-victim heuristic maintains a timestamp per executor thread that is updated every time a worker attempts to steal work. 989 \PAB{Explain the timestamp, \ie how is it formed?} 995 The timestamps are generated using @rdtsc@~\cite{} and are stored in a shared array, with one index per worker. 990 996 Thieves then attempt to steal from the worker with the oldest timestamp. 997 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. 991 998 This heuristic means that if two thieves look to steal at the same time, they likely attempt to steal from the same victim. 992 \PAB{This idea seems counter intuitive so what is the intuition?} 993 This consequence does increase the chance at contention among thieves; 999 This approach consequently does increase the chance at contention among thieves; 994 1000 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. 995 \PAB{Both of these theorems are commented out.} 996 Furthermore, in the case they attempt to steal the same queue, at least one of them is guaranteed to successfully steal the queue as shown in Theorem~\ref{t:one_vic}. 997 Additionally, the longest victim heuristic makes it very improbable that the no swap scenario presented in Theorem~\ref{t:vic_cycle} manifests. 998 Given the longest victim heuristic, for a cycle to manifest it requires all workers to attempt to steal in a short timeframe. 999 This scenario is the only way that more than one thief could choose another thief as a victim, since timestamps are only updated upon attempts to steal. 1000 In this case, the probability of an unsuccessful swap is rare, since it is likely these steals are not important when all workers are trying to steal. 1001 This approach may seem counter-intuitive, but in cases with not enough work to steal, the contention among thieves can result in less stealing, due to failed swaps. 1002 This can be beneficial when there is not enough work for all the stealing to be productive. 1003 This heuristic does not boast better performance than randomized victim selection, but it is comparable. 1004 However, it constitutes an interesting contribution as it shows that adding some complexity to the heuristic of the stealing fast path does not impact mainline performance, paving the way for more involved victim selection heuristics. 1005 % \PAB{Both of these theorems are commented out.} 1006 % Furthermore, in the case they attempt to steal the same queue, at least one of them is guaranteed to successfully steal the queue as shown in Theorem~\ref{t:one_vic}. 1007 % Additionally, the longest victim heuristic makes it very improbable that the no swap scenario presented in Theorem~\ref{t:vic_cycle} manifests. 1008 % Given the longest victim heuristic, for a cycle to manifest it requires all workers to attempt to steal in a short timeframe. 1009 % This scenario is the only way that more than one thief could choose another thief as a victim, since timestamps are only updated upon attempts to steal. 1010 % In this case, the probability of an unsuccessful swap is rare, since it is likely these steals are not important when all workers are trying to steal. 1001 1011 1002 1012 \section{Safety and Productivity}\label{s:SafetyProductivity}
Note: See TracChangeset
for help on using the changeset viewer.