Changeset d02aaa9 for doc


Ignore:
Timestamp:
Nov 15, 2016, 12:25:13 PM (8 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:
63c2bca
Parents:
4328016
Message:

Update intro up to internal scheduling

Location:
doc/proposals/concurrency
Files:
3 edited

Legend:

Unmodified
Added
Removed

  • doc/proposals/concurrency/concurrency.tex

    r4328016 rd02aaa9  
    11% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    22
    3 % inline code �...� (copyright symbol) emacs: C-q M-)
    4 % red highlighting �...� (registered trademark symbol) emacs: C-q M-.
    5 % blue highlighting �...� (sharp s symbol) emacs: C-q M-_
    6 % green highlighting �...� (cent symbol) emacs: C-q M-"
    7 % LaTex escape �...� (section symbol) emacs: C-q M-'
    8 % keyword escape �...� (pilcrow symbol) emacs: C-q M-^
     3% inline code ©...© (copyright symbol) emacs: C-q M-)
     4% red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
     5% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
     6% green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
     7% LaTex escape §...§ (section symbol) emacs: C-q M-'
     8% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
    99% math escape $...$ (dollar symbol)
    1010
    … …  
    100100
    101101\section{Introduction}
    102 This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based parallelism, message passing and implicit threading.
    103 
    104 There are actually two problems that need to be solved in the design of the concurrency for a programming language. Which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are more about performance, cost and resource utilization.
     102This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based, message passing and implicit threading.
     103
     104There are actually two problems that need to be solved in the design of the concurrency for a programming language: which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are more about performance, cost and resource utilization.
    105105
    106106%  #####  ####### #     #  #####  #     # ######  ######  ####### #     #  #####  #     #
    … …  
    113113
    114114\section{Concurrency}
    115 Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts. However, in languages that use routine calls as their core abstraction mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e. message passing versus routine call). Which in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, but effective use of the librairy will still have to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on non-concurrent constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to be possible to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes Monitors as the core concurrency construct.
     115Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared-state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts (channels\cit for example). However, in languages that use routine calls as their core abstraction mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e., message passing versus routine call). Which in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, but effective use of the librairy still has to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on basic constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes monitors as the core concurrency construct.
    116116
    117117% #     # ####### #     # ### ####### ####### ######   #####
    … …  
    144144
    145145\subsubsection{Call semantics} \label{call}
    146 The above monitor example displays some of their intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
    147 
    148 Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic large counter :
    149 
    150 \begin{lstlisting}
    151         mutex struct counter_t { /*...*/ };
    152 
    153         void ?{}(counter_t & nomutex this);
    154         size_t ++?(counter_t & mutex this);
     146The above monitor example displays some of the intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
     147
     148Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual-exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic counter :
     149
     150\begin{lstlisting}
     151        mutex struct counter_t { /*...see section §\ref{data}§...*/ };
     152
     153        void ?{}(counter_t & nomutex this); //constructor
     154        size_t ++?(counter_t & mutex this); //increment
    155155
    156156        //need for mutex is platform dependent here
    157         void ?{}(size_t * this, counter_t & mutex cnt);
    158 \end{lstlisting}
    159 *semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
    160 
    161 Here, the constructor(\code(?{})) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because object not yet constructed should never be shared and therefore do not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
    162 
    163 Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. If there were a meaning to routine \code{void foo(counter_t & this)} then one could argue that it should default to the safest option : \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that this is the more "normal" behavior, \code{nomutex} effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
    164 
    165 Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used as a type qualifier. Consider :
     157        void ?{}(size_t * this, counter_t & mutex cnt); //conversion
     158\end{lstlisting}
     159
     160Here, the constructor(\code{?\{\}}) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because an object not yet constructed should never be shared and therefore does not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
     161
     162Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. For example, given a routine without wualifiers \code{void foo(counter_t & this)} then one could argue that it should default to the safest option \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that \code{nomutex} is the more "normal" behaviour, the \code{nomutex} keyword effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
     163
     164The next semantic decision is to establish when mutex/nomutex may be used as a type qualifier. Consider the following declarations:
    166165\begin{lstlisting}
    167166        int f1(monitor & mutex m);
    … …  
    171170        int f5(graph(monitor*) & mutex m);
    172171\end{lstlisting}
    173 
    174 The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entering. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C and even then making sure we only acquire objects once becomes also none trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter (ignoring potential qualifiers and indirections). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} will be acquired, passing an array to this routine would be type safe and result in undefined behavior. For this reason, it would also be reasonnable to disallow mutex in the context where arrays may be passed.
     172The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In the case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entry. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C and even then making sure we only acquire objects once becomes also none trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter (ignoring potential qualifiers and indirections). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} is be acquired, passing an array to this routine would be type safe and yet result in undefined behavior because only the first element of the array is acquired. However, this ambiguity is part of the C type system with respects to arrays. For this reason, it would also be reasonnable to disallow mutex in the context where arrays may be passed.
    175173
    176174% ######     #    #######    #
    … …  
    183181
    184182\subsubsection{Data semantics} \label{data}
    185 Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contian shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appripriate protection. For example here is a more fleshed-out version of the counter showed in \ref{call}:
     183Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contian shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appropriate protection. For example, here is a complete version of the counter showed in section \ref{call}:
    186184\begin{lstlisting}
    187185        mutex struct counter_t {
    … …  
    203201\end{lstlisting}
    204202
    205 This simple counter offers an example of monitor usage. Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting :
     203This simple counter is used as follows:
    206204\begin{center}
    207205\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
    208206\begin{lstlisting}
     207        //shared counter
    209208        counter_t cnt;
    210209
     210        //multiple threads access counter
    211211        thread 1 : cnt++;
    212212        thread 2 : cnt++;
    … …  
    218218\end{center}
    219219
    220 These simple mutual exclusion semantics also naturally expand to multi-monitor calls.
     220Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. Unlike object-oriented monitors, where calling a mutex member \emph{implicitly} acquires mutual-exclusion, \CFA uses an explicit mechanism to acquire mutual-exclusion. A consequence of this approach is that it extends to multi-monitor calls.
    221221\begin{lstlisting}
    222222        int f(MonitorA & mutex a, MonitorB & mutex b);
    … …  
    226226        f(a,b);
    227227\end{lstlisting}
    228 
    229 This code acquires both locks before entering the critical section (Referenced as \gls{group-acquire} from now on). In practice, writing multi-locking routines that can not lead to deadlocks can be tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition will be consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquiring locks users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
    230 \begin{lstlisting}
    231         void foo(A & mutex a, B & mutex a) {
     228This code acquires both locks before entering the critical section, called \emph{\gls{group-acquire}}. In practice, writing multi-locking routines that do not lead to deadlocks is tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition is consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquisition locks, users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
     229\begin{lstlisting}
     230        void foo(A & mutex a, B & mutex b) { //acquire a & b
    232231                //...
    233232        }
    234233
    235         void bar(A & mutex a, B & nomutex a)
     234        void bar(A & mutex a, B & nomutex b) { //acquire a
    236235                //...
    237                 foo(a, b);
     236                foo(a, b); //acquire b
    238237                //...
    239238        }
    240239
    241         void baz(A & nomutex a, B & mutex a)
     240        void baz(A & nomutex a, B & mutex b) { //acquire b
    242241                //...
    243                 foo(a, b);
     242                foo(a, b); //acquire a
    244243                //...
    245244        }
    246245\end{lstlisting}
    247246
    248 Such a use will lead to nested monitor call problems~\cite{Lister77}, which are a specific implementation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlocks, depending on the implicit ordering matching the explicit ordering. As shown on several occasion\cit, solving this problems requires to :
     247The multi-acquisition monitor lock allows a monitor lock to be acquired by both \code{bar} or \code{baz} and acquired again in \code{foo}. In the calls to \code{bar} and \code{baz} the monitors are acquired in opposite order. such use leads to nested monitor call problems~\cite{Lister77}, which is a specific implementation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlock and is therefore undefined behavior. As shown on several occasion\cit, solving this problem requires :
    249248\begin{enumerate}
    250         \item Dynamically track the monitor call order.
     249        \item Dynamically tracking of the monitor-call order.
    251250        \item Implement rollback semantics.
    252251\end{enumerate}
    253252
    254 While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA users simply need to be carefull when acquiring multiple monitors at the same time.
     253While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA, users simply need to be carefull when acquiring multiple monitors at the same time.
    255254
    256255% ######  ####### #######    #    ### #        #####
    … …  
    271270
    272271\subsubsection{Implementation Details: Interaction with polymorphism}
    273 At first glance, interaction between monitors and \CFA's concept of polymorphism seem complex to support. However, it can be reasoned that entry-point locking can solve most of the issues that could be present with polymorphism.
    274 
    275 First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. \Gls{callsite-locking}\footnotemark would require a significant amount of work, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking}\footnotemark[\value{footnote}] calling a monitor routine becomes exactly the same as calling it from anywhere else.
    276 \footnotetext{See glossary for a definition of \gls{callsite-locking} and \gls{entry-point-locking}}
     272At first glance, interaction between monitors and \CFA's concept of polymorphism seems complex to support. However, it is shown that entry-point locking can solve most of the issues.
     273
     274Before looking into complex control flow, it is important to present the difference between the two acquiring options : \gls{callsite-locking} and \gls{entry-point-locking}, i.e. acquiring the monitors before making a mutex call or as the first instruction of the mutex call. For example:
     275
     276\begin{center}
     277\begin{tabular}{|c|c|c|}
     278Code & \gls{callsite-locking} & \gls{entry-point-locking} \\
     279\CFA & pseudo-code & pseudo-code \\
     280\hline
     281\begin{lstlisting}
     282void foo(monitor & mutex a) {
     283
     284
     285
     286        //Do Work
     287        //...
     288
     289}
     290
     291void main() {
     292        monitor a;
     293
     294
     295
     296        foo(a);
     297
     298}
     299\end{lstlisting} &\begin{lstlisting}
     300foo(& a) {
     301
     302
     303
     304        //Do Work
     305        //...
     306
     307}
     308
     309main() {
     310        monitor a;
     311        //calling routine
     312        //handles concurrency
     313        acquire(a);
     314        foo(a);
     315        release(a);
     316}
     317\end{lstlisting} &\begin{lstlisting}
     318foo(& a) {
     319        //called routine
     320        //handles concurrency
     321        acquire(a);
     322        //Do Work
     323        //...
     324        release(a);
     325}
     326
     327main() {
     328        monitor a;
     329
     330
     331
     332        foo(a);
     333
     334}
     335\end{lstlisting}
     336\end{tabular}
     337\end{center}
     338
     339First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore, the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. \Gls{callsite-locking} would require a significant amount of work, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking} calling a monitor routine becomes exactly the same as calling it from anywhere else.
     340
     341
    277342
    278343% ### #     # #######         #####   #####  #     # ####### ######
    … …  
    285350
    286351\subsection{Internal scheduling} \label{insched}
    287 Monitors also need to schedule waiting threads within it as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
     352Monitors also need to schedule waiting threads internally as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
    288353
    289354\begin{lstlisting}
    … …  
    303368\end{lstlisting}
    304369
    305 Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
     370Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
    306371\begin{center}
    307372\begin{tabular}{ c @{\hskip 0.65in} c }
    … …  
    337402condition e;
    338403
     404//acquire a & b
    339405void foo(monitor & mutex a,
    340406           monitor & mutex b) {
    341407
    342         wait(e);
     408        wait(e); //release a & b
    343409}
    344410
    … …  
    352418condition e;
    353419
     420//acquire a
    354421void bar(monitor & mutex a,
    355422           monitor & nomutex b) {
    … …  
    357424}
    358425
     426//acquire a & b
    359427void foo(monitor & mutex a,
    360428           monitor & mutex b) {
    361         wait(e);
     429        wait(e);  //release a & b
    362430}
    363431
    … …  
    366434condition e;
    367435
     436//acquire a
    368437void bar(monitor & mutex a,
    369438           monitor & nomutex b) {
    … …  
    371440}
    372441
     442//acquire b
    373443void baz(monitor & nomutex a,
    374444           monitor & mutex b) {
    375         wait(e);
     445        wait(e);  //release b
    376446}
    377447
    … …  
    381451\end{center}
    382452
    383 Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine wiht multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar} which only acquires monitor \code{a}. Since monitors can be acquired multiple times this will not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
     453Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine with multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar}, which only acquires monitor \code{a}. Since monitors can be acquired multiple times this does not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases, the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
    384454
    385455
    … …  
    389459condition e;
    390460
    391 //acquire a
     461//acquire b
    392462void foo(monitor & nomutex a,
    393463           monitor & mutex b) {
    … …  
    399469           monitor & nomutex b) {
    400470
    401         //release a
    402         //keep b
    403         wait(e);
     471        wait(e); //release a
     472                  //keep b
    404473}
    405474
    … …  
    418487           monitor & nomutex b) {
    419488
    420         //release b
    421         //keep a
    422         wait(e);
     489        wait(e); //release b
     490                  //keep a
    423491}
    424492
    … …  
    437505           monitor & nomutex b) {
    438506
    439         //release a & b
    440         //keep none
    441         wait(e);
     507        wait(e); //release a & b
     508                  //keep none
    442509}
    443510
    … …  
    446513\end{tabular}
    447514\end{center}
    448 Note the right-most example which uses a helper routine and therefore is not relevant to find which monitors will be released.
    449 
    450 These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors.
    451 
    452 Regardless of the context in which the \code{wait} statement is used, \code{signal} must used holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
     515Note the right-most example is actually a trick pulled on the reader. Monitor state information is stored in thread local storage rather then in the routine context, which means that helper routines and other \code{nomutex} routines are invisible to the runtime system in regards to concurrency. This means that in the right-most example, the routine parameters are completly unnecessary. However, calling this routine from outside a valid monitor context is undefined.
     516
     517These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors. In the center previous examples, the code in the center uses the \code{bar} routine to only release monitor \code{b}. Using the \code{wait_release} helper, this can be rewritten without having the name two routines :
     518\begin{center}
     519\begin{tabular}{ c c c }
     520\begin{lstlisting}
     521        condition e;
     522
     523        //acquire a & b
     524        void foo(monitor & mutex a,
     525                   monitor & mutex b) {
     526                bar(a,b);
     527        }
     528
     529        //acquire b
     530        void bar(monitor & mutex a,
     531                   monitor & nomutex b) {
     532
     533                wait(e); //release b
     534                          //keep a
     535        }
     536
     537        foo(a, b);
     538\end{lstlisting} &\begin{lstlisting}
     539        =>
     540\end{lstlisting} &\begin{lstlisting}
     541        condition e;
     542
     543        //acquire a & b
     544        void foo(monitor & mutex a,
     545                   monitor & mutex b) {
     546                wait_release(e,b); //release b
     547                                         //keep a
     548        }
     549
     550        foo(a, b);
     551\end{lstlisting}
     552\end{tabular}
     553\end{center}
     554
     555Regardless of the context in which the \code{wait} statement is used, \code{signal} must be called holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
    453556
    454557Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.

  • doc/proposals/concurrency/glossary.tex

    r4328016 rd02aaa9  
    1414
    1515\longnewglossaryentry{group-acquire}
    16 {name={grouped acquiring}}
     16{name={bulked acquiring}}
    1717{
    1818Implicitly acquiring several monitors when entering a monitor.

  • doc/proposals/concurrency/version

    r4328016 rd02aaa9  
    1 0.5.150
     10.6.30
Note: See TracChangeset for help on using the changeset viewer.