Changeset 64b272a for doc/proposals/concurrency/text/concurrency.tex

Timestamp:

Nov 2, 2017, 3:47:57 PM (7 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

e706bfd

Parents:

bd7f401

Message:

Prereview commit

File:

• doc/proposals/concurrency/text/concurrency.tex (modified) (2 diffs)

doc/proposals/concurrency/text/concurrency.tex

@@ -221 +221 @@
 % ======================================================================
 % ======================================================================
-\section{Internal scheduling} \label{insched}
+\section{Internal scheduling} \label{intsched}
 % ======================================================================
 % ======================================================================
@@ -973 +973 @@
 \label{lst:waitfor2}
 \end{figure}
+
+% ======================================================================
+% ======================================================================
+\subsection{Waiting for the destructor}
+% ======================================================================
+% ======================================================================
+An important exception for the \code{waitfor} statement is destructor semantics. Indeed, the \code{waitfor} statement can accept any \code{mutex} routine, which counts the destructor. However, with the semantics discussed until now, waiting for the destructor does not make any sense since using an object after its destructor is called is undefined behaviour. The simplest approach to fix this hole in the semantics would be disallowing \code{waitfor} on destructor. However, a more expressive approach is to flip ordering of execution when waiting for the destructor, meaning that waiting for the destructor allows the destructor to run after the current \code{mutex} routine, similarly to how a condition is signalled.
+\begin{figure}
+\begin{cfacode}
+monitor Executer {};
+struct  Action;
+
+void ^?{}   (Executer & mutex this);
+void execute(Executer & mutex this, const Action & );
+void run    (Executer & mutex this) {
+        while(true) {
+                   waitfor(execute, this);
+                or waitfor(^?{}   , this) {
+                        break;
+                }
+        }
+}
+\end{cfacode}
+\caption{Example of an executor which executes action in series until the destructor is called.}
+\label{lst:dtor-order}
+\end{figure}
+For example, listing \ref{lst:dtor-order} shows an example of an executor with an infinite loop, which waits for the destructor to break out of this loop.