Ignore:
Timestamp:
Nov 2, 2017, 3:47:57 PM (4 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
e706bfd
Parents:
bd7f401
Message:

Prereview commit

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/concurrency/text/concurrency.tex

    rbd7f401 r64b272a  
    221221% ======================================================================
    222222% ======================================================================
    223 \section{Internal scheduling} \label{insched}
     223\section{Internal scheduling} \label{intsched}
    224224% ======================================================================
    225225% ======================================================================
     
    973973\label{lst:waitfor2}
    974974\end{figure}
     975
     976% ======================================================================
     977% ======================================================================
     978\subsection{Waiting for the destructor}
     979% ======================================================================
     980% ======================================================================
     981An 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.
     982\begin{figure}
     983\begin{cfacode}
     984monitor Executer {};
     985struct  Action;
     986
     987void ^?{}   (Executer & mutex this);
     988void execute(Executer & mutex this, const Action & );
     989void run    (Executer & mutex this) {
     990        while(true) {
     991                   waitfor(execute, this);
     992                or waitfor(^?{}   , this) {
     993                        break;
     994                }
     995        }
     996}
     997\end{cfacode}
     998\caption{Example of an executor which executes action in series until the destructor is called.}
     999\label{lst:dtor-order}
     1000\end{figure}
     1001For 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.
Note: See TracChangeset for help on using the changeset viewer.