From 9852e626676a1cc6239780ba977c0279251eeb94 Mon Sep 17 00:00:00 2001 From: Elliot Ronaghan Date: Wed, 9 Oct 2024 14:14:25 -0400 Subject: [PATCH 1/3] Add Matthew Davis to contributors --- content/coverpage.tex | 1 + 1 file changed, 1 insertion(+) diff --git a/content/coverpage.tex b/content/coverpage.tex index e26a54ca..09d319e1 100644 --- a/content/coverpage.tex +++ b/content/coverpage.tex @@ -60,6 +60,7 @@ \subsection*{\openshmem 1.6} \item Aurelien Bouteiller, \ac{UTK} \item Mark Brown, Intel \item Bob Cernohous, \ac{HPE} +\item Matthew Davis, Georgia Tech \item James Dinan\footnotemark[1], NVIDIA \item Megan Grodowitz, Arm Inc. \item Max Grossman, Georgia Tech From 9be6e038f12a9a65c9349e47b39ef2c9f7f2dc28 Mon Sep 17 00:00:00 2001 From: Elliot Ronaghan Date: Wed, 9 Oct 2024 15:35:01 -0400 Subject: [PATCH 2/3] Add shmem_team_ptr to SHMEM_TEAM_SHARED description --- content/library_handles.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/library_handles.tex b/content/library_handles.tex index 6040a61e..8c6faa3e 100644 --- a/content/library_handles.tex +++ b/content/library_handles.tex @@ -25,8 +25,8 @@ Handle of type \CTYPE{shmem\_team\_t} that corresponds to a team of \acp{PE} that share a memory domain. \LibHandleRef{SHMEM\_TEAM\_SHARED} refers to the team of all PEs that would mutually return a non-null address from a -call to \FUNC{shmem\_ptr} for all symmetric heap objects. That is, -\FUNC{shmem\_ptr} must return a non-null pointer to the local PE for all +call to \FUNC{shmem\_ptr} or \FUNC{shmem\_team\_ptr} for all symmetric heap objects. That is, +\FUNC{shmem\_ptr} and \FUNC{shmem\_team\_ptr} must return a non-null pointer to the local PE for all symmetric heap objects on all target \acp{PE} in the team. This means that symmetric heap objects on each \ac{PE} are directly load/store accessible by all \acp{PE} in the team. From 4873b2535a444c9e30a96cd0cd968733b1ad7745 Mon Sep 17 00:00:00 2001 From: Elliot Ronaghan Date: Wed, 9 Oct 2024 16:12:15 -0400 Subject: [PATCH 3/3] Add definition of remote PE The term "remote PE" is used widely in the spec even in cases where the PE can be node-local or even the same PE. In many cases "target PE" might be a better term, but given the widespread use and time constraints for the 1.6 spec we've opted to just define the term to include be all remotely accessible PEs. --- content/programming_model_overview.tex | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/programming_model_overview.tex b/content/programming_model_overview.tex index 6d53ece1..e30ef792 100644 --- a/content/programming_model_overview.tex +++ b/content/programming_model_overview.tex @@ -2,7 +2,10 @@ mechanisms to share information among \openshmem processes, or \acp{PE}, and private data objects that are accessible by only the \ac{PE} itself. The \ac{API} allows communication and synchronization operations on both private (local to -the \ac{PE} initiating the operation) and remotely accessible data objects. The key +the \ac{PE} initiating the operation) and remotely accessible data objects. A +remote \ac{PE} is defined as any \ac{PE} whose remotely accessible data objects +are accessible to the \ac{PE} initiating an operation and may include the +initiating \ac{PE}. The key feature of \openshmem is that data transfer operations are \emph{one-sided} in nature. This means that a local \ac{PE} executing a data transfer routine does not require the participation of the remote \ac{PE}