Update concept for execution space instances (#581)

* wake and sleep don't exist anymore

* Remove in_parallel

* Use SemiRegular

* Document concurrency

* Add fence without argument

* Update docs/source/API/core/execution_spaces.rst

Co-authored-by: Damien L-G <dalg24+github@gmail.com>

* SemiRegular -> Regular

* Apply suggestions from code review

Co-authored-by: Damien L-G <dalg24+github@gmail.com>

---------

Co-authored-by: Damien L-G <dalg24+github@gmail.com>

docs/source/API/core/KokkosConcepts.rst

@@ -102,9 +102,7 @@ and ``OpenMPTarget``, the current state of the Kokkos |ExecutionSpaceTwo|_ conce
 
     template <typename Ex>
     concept ExecutionSpace =
-        CopyConstructible<Ex> &&
-        DefaultConstructible<Ex> &&
-        Destructible<Ex> &&
+        std::regular<Ex> &&
         // Member type requirements:
         requires() {
             typename Ex::execution_space;
@@ -120,10 +118,11 @@ and ``OpenMPTarget``, the current state of the Kokkos |ExecutionSpaceTwo|_ conce
             typename Ex::device_type;
         } &&
         // Required methods:
-        requires(Ex ex, std::ostream& ostr, bool detail) {
-            { ex.in_parallel() } -> bool;
+        requires(Ex ex, std::string str, std::ostream& ostr, bool detail) {
+            { ex.fence(str) };
             { ex.fence() };
             { ex.name() } -> const char*;
+            { ex.concurrency() } -> int;
             { ex.print_configuration(ostr) };
             { ex.print_configuration(ostr, detail) };
         } &&
@@ -207,23 +206,6 @@ Support for ``UniqueToken`` adds the following requirements:
         && CopyConstructible<Experimental::UniqueToken<Ex, Experimental::UniqueTokenScope::Global>>
         && DefaultConstructible<Experimental::UniqueToken<Ex, Experimental::UniqueTokenScope::Global>>;
 
-An Additional Concept for ``DeviceExecutionSpace``?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-All the device execution spaces, in their current state, have two extra member functions,
-``sleep()`` and ``wake()``.  It's unclear whether this is intended to be general,
-but if it is, there is an additional concept in the hierarchy:
-
-.. code-block:: cpp
-
-    template <typename Ex>
-    concept DeviceExecutionSpace =
-        ExecutionSpace<Ex> &&
-        requires(Ex ex) {
-            { ex.sleep() };
-            { ex.wake() };
-        }
-
 Some *de facto* Requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -232,14 +214,6 @@ such as ``Impl::TeamPolicyInternal``. These also qualify as "requirements" on an
 just like ``Impl::ParallelFor<...>``. In many of these cases, it would be nice if we could refactor
 some things to use a less "all-or-nothing" approach to customization than partial class template specialization.
 
-Design Thoughts
-~~~~~~~~~~~~~~~
-
-The first thing that comes to mind is that ``CopyConstructible<T> && DefaultConstructible<T> && Destructible<T>``
-is very close to ``SemiRegular<T>``; all we need to do is add ``operator==()``.
-
-TODO more here
-
 The ``MemorySpace`` Concept
 ---------------------------
 

docs/source/API/core/execution_spaces.rst

@@ -210,16 +210,9 @@ and an instance of that type ``ex``, Kokkos guarantees the following expressions
 
 .. code-block:: cpp
 
-    ex.in_parallel();
+    ex.fence(str);
 
-*Returns:* a value convertible to ``bool`` indicating whether or not the caller is executing as part of a Kokkos parallel pattern.
-*Note:* as currently implemented, there is no guarantee that ``true`` means the caller is necessarily executing as part of a pattern on the particular instance ``ex``; just *some* instance of ``Ex``. This may be strengthened in the future.
-
-.. code-block:: cpp
-
-    ex.fence();
-
-*Effects:* Upon return, all parallel patterns executed on the instance ``ex`` are guaranteed to have completed, and their effects are guaranteed visible to the calling thread.
+*Effects:* Upon return, all parallel patterns and deep_copy calls executed on the instance ``ex`` are guaranteed to have completed, and their effects are guaranteed visible to the calling thread. The optiopnal ``str`` argument allows customizing the event reported to Kokkos Tools.
 *Returns:* Nothing.
 *Note:* This *cannot* be called from within a parallel pattern.  Doing so will lead to unspecified effects (i.e., it might work, but only for some execution spaces, so be extra careful not to do it).
 
@@ -280,9 +273,9 @@ Synopsis
         void print_configuration(std::ostream ostr&) const;
         void print_configuration(std::ostream ostr&, bool details) const;
 
-        bool in_parallel() const;
         int concurrency() const;
 
+        void fence(const std::string&) const;
         void fence() const;
 
         friend bool operator==(const execution_space& lhs, const execution_space& rhs);
@@ -325,11 +318,9 @@ Functions
 
 * ``const char* name() const;``: *Returns* the label of the execution space instance.
 
-* ``bool in_parallel() const;``: *Returns* a value convertible to ``bool`` indicating whether the caller is executing as part of a Kokkos parallel pattern. *Note:* as currently implemented, there is no guarantee that ``true`` means the caller is necessarily executing as part of a pattern on the particular instance |ExecutionSpaceConcept|_; just *some* instance of |ExecutionSpaceConcept|_. This may be strengthened in the future.
-
 * ``int concurrency() const;`` *Returns* the maximum amount of concurrently executing work items in a parallel setting, i.e. the maximum number of threads utilized by an execution space instance.
 
-* ``void fence() const;`` *Effects:* Upon return, all parallel patterns executed on the instance |ExecutionSpaceConcept|_ are guaranteed to have completed, and their effects are guaranteed visible to the calling thread. *Note:* This *cannot* be called from within a parallel pattern. Doing so will lead to unspecified effects (i.e., it might work, but only for some execution spaces, so be extra careful not to do it).
+* ``void fence(const std::string& label = unspecified-default-value) const;`` *Effects:* Upon return, all parallel patterns executed on the instance |ExecutionSpaceConcept|_ are guaranteed to have completed, and their effects are guaranteed visible to the calling thread. *Note:* This *cannot* be called from within a parallel pattern. Doing so will lead to unspecified effects (i.e., it might work, but only for some execution spaces, so be extra careful not to do it). The optional ``label`` argument allows customizing the event reported to Kokkos Tools.
 
 * ``void print_configuration(std::ostream ostr) const;``: *Effects:* Outputs the configuration of ``ex`` to the given ``std::ostream``. *Note:* This *cannot* be called from within a parallel pattern.