Changeset 7e10773


Ignore:
Timestamp:
Sep 30, 2016, 10:04:25 AM (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:
c69adb7
Parents:
aee7e35
Message:

further progress on concurrency part

Location:
doc/proposals/concurrency
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • doc/proposals/concurrency/citations.bib

    raee7e35 r7e10773  
    2323
    2424@mastersthesis{Bilson:CFA,
    25     keywords    = {Cforall, Overloading, Polymorphism},
    26     author  = {Richard C. Bilson},
    27     title   = {Implementing Overloading and Polymorphism in Cforall},
    28     school = "University of Waterloo",
    29     year = "2003"
     25    keywords            = {Cforall, Overloading, Polymorphism},
     26    author      = {Richard C. Bilson},
     27    title       = {Implementing Overloading and Polymorphism in Cforall},
     28    school              = "University of Waterloo",
     29    year                = "2003"
    3030}
    3131
    3232@article{HPP:Study,
    33         title = {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers}
     33        keywords        = {Parallel, Productivity},
     34        author  = {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz },
     35        title   = {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers},
    3436}
    3537@article{CFA:Refrat,
    3638    keywords    = {Cforall, refrat},
    37     author      = {Glen Ditchfield},
    38     title       = {Cforall Reference Manual and Rationale},
    39     month       = jan,
    40     year        = 2003
     39    author              = {Glen Ditchfield},
     40    title               = {Cforall Reference Manual and Rationale},
     41    month               = jan,
     42    year                = 2003
     43}
     44
     45@article{Chicken,
     46        keywords        = {Chicken},
     47        author  = {Doug Zongker},
     48        title           = {Chicken Chicken Chicken: Chicken Chicken},
     49        year            = 2006
     50}
     51
     52@article{Myths,
     53        author  = {Peter A. Buhr and Ashif S. Harji},
     54        title   = {Concurrent Urban Legends},
     55        year            = 2005
    4156}
    4257
    4358@article{uCPP:Book,
    44     keywords    = {uC++, manual, book},
    45     author  = {Peter A. Buhr},
    46     title   = {Understanding Control Flow with Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    47     month   = aug,
    48     year    = 2014
     59    keywords            = {uC++, manual, book},
     60    author      = {Peter A. Buhr},
     61    title       = {Understanding Control Flow with Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
     62    month       = aug,
     63    year        = 2014
    4964}
    5065
    5166@techreport{ISO:Ada,
    52     type = {International Standard},
    53     key = {ISO/IEC 8652:1995},
    54     year = {1995},
    55     title = {Ada},
    56     volume = {1995},
    57     institution = {International Organization for Standardization}
     67    type                = {International Standard},
     68    key                 = {ISO/IEC 8652:1995},
     69    year                = {1995},
     70    title               = {Ada},
     71    volume              = {1995},
     72    institution         = {International Organization for Standardization}
    5873}

  • doc/proposals/concurrency/concurrency.tex

    raee7e35 r7e10773  
    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
    … …  
    2424\usepackage{graphicx}
    2525\usepackage{tabularx}
    26 \usepackage{varioref}                                                                   % extended references
     26\usepackage{varioref}                                                           % extended references
     27\usepackage{inconsolata}
    2728\usepackage{listings}                                                                   % format program code
    2829\usepackage[flushmargin]{footmisc}                                              % support label/reference in footnote
    … …  
    5455\newcommand{\uC}{$\mu$\CC}
    5556\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace}
     57\newcommand{\code}[1]{\lstinline{#1}}
    5658
    5759
    … …  
    7779\section{Introduction}
    7880This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build "higher level" features. The simplest possible core is a thread and a lock but this low level approach is hard to master. An easier approach for users is be to support higher level construct as the basis of the concurrency in \CFA.
    79 Indeed, for higly productive parallel programming high-level approaches are much more popular. Examples are task based parallelism, message passing, implicit threading.
    80 
    81 There are actually to problems that need to be solved in the design of the concurrency for a 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. Concurrency tools need to handle mutual exclusion and synchronization while parallelism tools are more about performance, cost and ressource utilisation.
     81Indeed, for higly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading.
     82
     83There are actually two problems that need to be solved in the design of the concurrency for a 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{Myths}. Concurrency tools need to handle mutual exclusion and synchronization while parallelism tools are more about performance, cost and ressource utilisation.
    8284
    8385\section{Concurrency}
    84 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 states completely (Erlang, Haskel, Akka (Scala))\cit. In the paradigms, interaction between concurrent objects rely on message passing or other paradigms that often closely relate to networking concepts. However, in imperative or OO languages these approaches entail a clear distinction between concurrent and non concurrent paradigms. Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective at their jobs. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely
    85 
    86 Finally, an approach that is gaining in popularity is transactionnal memory\cit. However, 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.
     86Several 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 completely (Erlang, Haskel, Akka (Scala))\cit. In the paradigms, interaction between concurrent objects rely on message passing or other paradigms that often closely relate to networking concepts. However, in imperative or OO languages these approaches entail a clear distinction between concurrent and non concurrent paradigms. Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective at their jobs. 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. However for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm\cite{HPP:Study}. This paper proposes Monitors\cit as the core concurrency construct.
     87
     88Finally, an approach that is worth mentionning because it is gaining in popularity is transactionnal memory\cit. However, 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.
    8789
    8890\section{Monitors}
    89 A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java\cit or \uC\cit but does not strictly require OOP semantics. The only requirements is to be able to declare a handle to a shared object and a set of routines that act on it :
    90 \begin{lstlisting}
    91         typedef \*some monitor type*\ monitor;
    92         int f(monitor& m);
     91A monitor is a set of routines that ensure mutual exclusion when accessing shared state. This concept is generally associated with Object-Oriented Languages like Java\cit or \uC\cite{uCPP:Book} but does not strictly require OOP semantics. The only requirements is to be able to declare a handle to a shared object and a set of routines that act on it :
     92\begin{lstlisting}
     93        typedef /*some monitor type*/ monitor;
     94        int f(monitor & m);
    9395
    9496        int main() {
    … …  
    98100\end{lstlisting}
    99101
    100 \subsection{Call semantics}
     102\subsection{Call semantics} \label{call}
    101103The above example of monitors already displays some of their intrinsic caracteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because since at their core, monitors are simply implicit mutual exclusion objects (locks) and copying semantics of these is ill defined. Therefore, monitors are implicitly non-copyable.
    102104
    103 Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed to helper routines that do not acquire the monitor mutual exclusion on entry. Examples of this can be both external helper routines (\texttt{swap}, \texttt{sort}, etc.) or internal helper routines like the following example :
    104 
    105 \begin{lstlisting}
    106 
    107 \end{lstlisting}
    108 
    109 Having both \texttt{mutex} and \texttt{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 \texttt{h} then one could argue that it should be to default to \texttt{mutex} to be safe by default. On the other hand, making one of these keywords mandatory would provide the same semantics but without the ambiguity of supporting routine \texttt{h}. Mandatory keywords would also have the added benefice of being more clearly self-documented. In any case, the option of having routine \texttt{h} mean \texttt{nomutex} should be rejected since it is unsafe by default and may easily cause subtle errors.
    110 
    111 Furthermore, it is important to establish when mutex/nomutex may be used depending on type parameters.
    112 \begin{lstlisting}
    113         int f01(monitor& mutex m);
    114         int f02(const monitor& mutex m);
    115         int f03(monitor* mutex m);
    116         int f04(monitor* mutex * m);
    117         int f05(monitor** mutex m);
     105Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed to helper routines that do not acquire the monitor mutual exclusion on entry. Examples of this can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following example :
     106
     107\begin{lstlisting}
     108        mutex struct counter_t { /*...*/ };
     109
     110        void ?{}(counter_t & mutex this);
     111        int ++?(counter_t & mutex this);
     112        void ?{}(int * this, counter_t & mutex cnt);
     113
     114        bool is_zero(counter_t & nomutex this) {
     115                int val = this;
     116                return val == 0;
     117        }
     118\end{lstlisting}
     119*semantics of the declaration of \code{mutex struct counter_t} will be discussed in details in \ref{data}
     120
     121This is an example of a monitor used as safe(ish) counter for concurrency. This API, which offers the prefix increment operator and a conversion operator to \code{int}, guarantees that reading the value (by converting it to \code{int}) and incrementing it are mutually exclusive. Note that the \code{is_zero} routine uses the \code{nomutex} keyword. Indeed, since reading the value is already atomic, there is no point in maintaining the mutual exclusion once the value is copied locally (in the variable \code{val} ).
     122
     123Having 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 be to 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". An other alternative is to make 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 more clearly 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 will be used for the sake of clarity.
     124
     125Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
     126\begin{lstlisting}
     127        int f01(monitor & mutex m);
     128        int f02(const monitor & mutex m);
     129        int f03(monitor * mutex m);
     130        int f04(monitor * mutex * m);
     131        int f05(monitor ** mutex m);
    118132        int f06(monitor[10] mutex m);
    119133        int f07(monitor[] mutex m);
    120         int f08(vector(monitor)& mutex m);
    121         int f09(list(monitor)& mutex m);
    122         int f10([monitor*, int]& mutex m);
    123         int f11(graph(monitor*)& mutex m);
    124 \end{lstlisting}
    125 
    126 For the first routines it seems to make sense to support the mutex keyword for such small variations. The difference between pointers and reference (\texttt{f01} vs \texttt{f03}) or const and non-const (\texttt{f01} vs \texttt{f02}) has no significance to mutual exclusion. It may not always make sense to acquire the monitor when extra dereferences (\texttt{f04}, \texttt{f05}) are added but it is still technically feasible and the present of the explicit mutex keywork does make it very clear of the user's intentions. Passing in a known-sized array(\texttt{f06}) is also technically feasible but is close to the limits. Indeed, the size of the array is not actually enforced by the compiler and if replaced by a variable-sized array (\texttt{f07}) or a higher-level container (\texttt{f08}, \texttt{f09}) it becomes much more complex to properly acquire all the locks needed for such a complex critical section. This implicit acquisition also poses the question of what qualifies as a container. If the mutex keyword is supported on monitors stored inside of other types it can quickly become complex and unclear which monitor should be acquired and when. The extreme example of this is \texttt{f11} which takes a possibly cyclic graph of pointers to monitors. With such a routine signature the intuition of which monitors will be acquired on entry is lost. Where to draw the lines is up for debate but it seems reasonnable to consider \texttt{f03} as accepted and \texttt{f06} as rejected.
    127 
    128 \subsection{Data semantics}
    129 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 :
     134        int f08(vector(monitor) & mutex m);
     135        int f09(list(monitor) & mutex m);
     136        int f10([monitor*, int] & mutex m);
     137        int f11(graph(monitor*) & mutex m);
     138\end{lstlisting}
     139
     140For the first few routines it seems to make sense to support the mutex keyword for such small variations. The difference between pointers and reference (\code{f01} vs \code{f03}) or const and non-const (\code{f01} vs \code{f02}) has no significance to mutual exclusion. It may not always make sense to acquire the monitor when extra dereferences (\code{f04}, \code{f05}) are added but it is still technically feasible and the present of the explicit mutex keywork does make it very clear of the user's intentions. Passing in a known-sized array(\code{f06}) is also technically feasible but is close to the limits. Indeed, the size of the array is not actually enforced by the compiler and if replaced by a variable-sized array (\code{f07}) or a higher-level container (\code{f08}, \code{f09}) it becomes much more complex to properly acquire all the locks needed for such a complex critical section. This implicit acquisition also poses the question of what qualifies as a container. If the mutex keyword is supported on monitors stored inside of other types it can quickly become complex and unclear which monitor should be acquired and when. The extreme example of this is \code{f11} which takes a possibly cyclic graph of pointers to monitors. With such a routine signature the intuition of which monitors will be acquired on entry is lost\cite{Chicken}. Where to draw the lines is up for debate but it seems reasonnable to consider \code{f03} as accepted and \code{f06} as rejected.
     141
     142\subsection{Data semantics} \label{data}
     143Once 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}:
    130144\begin{lstlisting}
    131145        mutex struct counter_t {
    … …  
    133147        };
    134148
    135         void ?{}(counter_t& mutex this) {
     149        void ?{}(counter_t & mutex this) {
    136150                this.cnt = 0;
    137151        }
    138152
    139         int ++?(counter_t& mutex this) {
     153        int ++?(counter_t & mutex this) {
    140154                return ++this->value;
    141155        }
    142156
    143         void ?{}(int* this, counter_t& mutex cnt) {
     157        void ?{}(int * this, counter_t & mutex cnt) {
    144158                *this = (int)cnt;
    145159        }
    … …  
    148162Thread 1 & Thread 2 \\
    149163\begin{lstlisting}
    150         void main(counter_t& mutex c) {
     164        void main(counter_t & mutex c) {
    151165                for(;;) {
    152166                        int count = c;
    … …  
    154168                }
    155169        }
    156 \end{lstlisting}&\begin{lstlisting}
    157         void main(counter_t& mutex c) {
     170\end{lstlisting} &\begin{lstlisting}
     171        void main(counter_t & mutex c) {
    158172                for(;;) {
    159173                        ++c;
    … …  
    166180
    167181
    168 This simple counter monitor offers an example of monitor usage. Notice how the counter is used without any explicit synchronisation and yet is perfectly safe reglardless of how many threads use it simultaneously. \\
     182This 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. \\
    169183
    170184These simple mutual exclusion semantics also naturally expand to multi-monitor calls.
    171185\begin{lstlisting}
    172         int f(MonitorA& mutex a, MonitorB& mutex b);
     186        int f(MonitorA & mutex a, MonitorB & mutex b);
    173187
    174188        MonitorA a;
    … …  
    176190        f(a,b);
    177191\end{lstlisting}
    178 This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, as the this proposal shows, this does have significant repercussions relating to scheduling. The ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example :
    179 \begin{lstlisting}
    180         void foo(A& mutex a, B& mutex a) {
    181                 //...
    182         }
    183 
    184         void bar(A& mutex a, B& mutex a)
     192
     193This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, as the this proposal shows, this does have significant repercussions relating to scheduling (see \ref{insched} and \ref{extsched}). The ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example :
     194\begin{lstlisting}
     195        void foo(A & mutex a, B & mutex a) {
     196                //...
     197        }
     198
     199        void bar(A & mutex a, B & nomutex a)
    185200                //...
    186201                foo(a, b);
    187202                //...
    188203        }
    189 \end{lstlisting}
    190 
    191 
    192 % Here, there is a language design choice that has to be made. It is impossible to protect the user from both barging and deadlocks and therefore this code has the potential to deadlock if some other threads try to acquire the locks in a different order (keep in mind that the lock ordering may be invisible or non-deterministic). The alternative is to allow the algorithm to release the lock on monitor \texttt{a}. This would effectively prevent the deadlock but could also mean that mutual exclusion may be dropped in the midle of routine \texttt{bar}.
    193 %
    194 % Indeed, there are two options for acquiring multiple locks while preventing deadlocks. The first option is to prescribe some arbitrary order of locking. If used consistently in the application this solution is both deadlock-free and barging-free. However, it also relies on the user to consistently follow the ordering when manually specifying the order. If the lock ordering is based on lock creation order or heap address ordering, it may be impossible for users to statically predict the correct lock acquiring order which means that deadlocks are a very real possibility. On the other hand, if the locking algorithm tries to dynamically find the correct lock ordering then it must release all locks after each wrong ordering attempts. This does not cause any significant issue in the context where a users tries to acquire multiple locks at once since the thread is not already in a critical section. However, if the thread was already holding a lock then releasing all locks on failed attempts may mean violating the mutual exclusion of the critical section. Notice that this is only an issue when nested mutex routines are used, in any other case monitors will behave consistently between both algorithms. Since releasing a lock in the middle of a critical section effectively violates mutual exclusion, it seems reasonnable to reject algorithms that dynamically guess the order of lock acquiring since users need to be very comfortable with multi-lock semantics before they can expect nested monitor calls to end-up releasing locks.
    195 
    196 
    197 \subsubsection{Internal scheduling}
     204
     205        void baz(A & nomutex a, B & mutex a)
     206                //...
     207                foo(a, b);
     208                //...
     209        }
     210\end{lstlisting}
     211
     212TODO: dig further into monitor order aquiring
     213
     214Thoughs : calls to \code{baz} and \code{bar} are definitely incompatible because they explicitly acquire locks in reverse order and therefore are explicitly asking for a deadlock. The best that can be done in this situatuin is to detect the deadlock. The case of implicit ordering is less clear because in the case of monitors the runtime system \textit{may} be smart enough to figure out that someone is waiting with explicit ordering... maybe.
     215
     216\subsubsection{Internal scheduling} \label{insched}
    198217Monitors should also be able to schedule what threads access 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 wait for them to be signaled. Here is a simple example of such a technique :
    199218
    … …  
    203222        }
    204223
    205         void foo(A& mutex a) {
     224        void foo(A & mutex a) {
    206225                //...
    207226                wait(a.e);
    … …  
    209228        }
    210229
    211         void bar(A& mutex a) {
     230        void bar(A & mutex a) {
    212231                signal(a.e);
    213232        }
    214233\end{lstlisting}
    215234
    216 Here routine \texttt{foo} waits on the \texttt{signal} from \texttt{bar} before making further progress, effectively ensuring a basic ordering. This can easily be extended to multi-monitor calls by offering the same guarantee.
    217 
    218 \begin{tabular}{ c c }
     235Here routine \code{foo} waits on the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This can easily be extended to multi-monitor calls by offering the same guarantee.
     236
     237\begin{center}
     238\begin{tabular}{ c @{\hskip 0.65in} c }
    219239Thread 1 & Thread 2 \\
    220240\begin{lstlisting}
    221 void foo(monitor& mutex a, monitor& mutex b) {
     241void foo(monitor & mutex a,
     242         monitor & mutex b) {
    222243        //...
    223244        wait(a.e);
    … …  
    226247
    227248foo(a, b);
    228 \end{lstlisting}&\begin{lstlisting}
    229 void bar(monitor& mutex a, monitor& mutex b) {
     249\end{lstlisting} &\begin{lstlisting}
     250void bar(monitor & mutex a,
     251         monitor & mutex b) {
    230252        signal(a.e);
    231253}
    … …  
    236258\end{lstlisting}
    237259\end{tabular}
    238 \\
     260\end{center}
    239261
    240262A direct extension of the single monitor semantics would be to release all locks when waiting and transferring ownership of all locks when signalling. However, for the purpose of synchronization it may be usefull to only release some of the locks but keep others. On the technical side, partially releasing lock is feasible but from the user perspective a choice must be made for the syntax of this feature. It is possible to do without any extra syntax by relying on order of acquisition :
    241263
     264\begin{center}
    242265\begin{tabular}{|c|c|c|}
    243266Context 1 & Context 2 & Context 3 \\
    244267\hline
    245268\begin{lstlisting}
    246 void foo(monitor& mutex a,
    247          monitor& mutex b) {
     269void foo(monitor & mutex a,
     270         monitor & mutex b) {
    248271        wait(a.e);
    249272}
    … …  
    255278
    256279foo(a,b);
    257 \end{lstlisting}&\begin{lstlisting}
    258 void bar(monitor& mutex a,
    259          monitor& nomutex b) {
     280\end{lstlisting} &\begin{lstlisting}
     281void bar(monitor & mutex a,
     282         monitor & nomutex b) {
    260283        foo(a,b);
    261284}
    262285
    263 void foo(monitor& mutex a,
    264          monitor& mutex b) {
     286void foo(monitor & mutex a,
     287         monitor & mutex b) {
    265288        wait(a.e);
    266289}
    267290
    268291bar(a, b);
    269 \end{lstlisting}&\begin{lstlisting}
    270 void bar(monitor& mutex a,
    271          monitor& nomutex b) {
     292\end{lstlisting} &\begin{lstlisting}
     293void bar(monitor & mutex a,
     294         monitor & nomutex b) {
    272295        foo(a,b);
    273296}
    274297
    275 void baz(monitor& nomutex a,
    276          monitor& mutex b) {
     298void baz(monitor & nomutex a,
     299         monitor & mutex b) {
    277300        wait(a.e);
    278301}
    … …  
    281304\end{lstlisting}
    282305\end{tabular}
    283 \\
    284 
    285 This can be interpreted in two different ways.
     306\end{center}
     307
     308This can be interpreted in two different ways :
    286309\begin{enumerate}
    287         \item \texttt{wait} atomically releases the monitors \underline{theoretically} acquired by the inner-most mutex routine.
    288         \item \texttt{wait} atomically releases the monitors \underline{actually} acquired by the inner-most mutex routine.
     310        \item \code{wait} atomically releases the monitors \underline{theoretically} acquired by the inner-most mutex routine.
     311        \item \code{wait} atomically releases the monitors \underline{actually} acquired by the inner-most mutex routine.
    289312\end{enumerate}
    290 While the difference between these two is subtle, it has a significant impact. In the first case it means that the calls to \texttt{foo} would behave the same in Context 1 and 2. This semantic would also mean that the call to \texttt{wait} in routine \texttt{baz} would only release \texttt{monitor b}. While this may seem intuitive with these examples, it does have one significant implication, it creates a strong distinction between acquiring multiple monitors in sequence and acquiring the same monitors simulatenously.
     313While the difference between these two is subtle, it has a significant impact. In the first case it means that the calls to \code{foo} would behave the same in Context 1 and 2. This semantic would also mean that the call to \code{wait} in routine \code{baz} would only release \code{monitor b}. While this may seem intuitive with these examples, it does have one significant implication, it creates a strong distinction between acquiring multiple monitors in sequence and acquiring the same monitors simulatenously.
    291314
    292315\begin{center}
    293 \begin{tabular}{c c c}
     316\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
    294317\begin{lstlisting}
    295318enterMonitor(a);
    … …  
    298321leaveMonitor(b);
    299322leaveMonitor(a);
    300 \end{lstlisting}& != &\begin{lstlisting}
     323\end{lstlisting} & != &\begin{lstlisting}
    301324enterMonitor(a);
    302325enterMonitor(a, b);
    … …  
    308331\end{center}
    309332
    310 This is not intuitive because even if both methods will display the same monitors state both inside and outside the critical section respectively, the behavior is different. Furthermore, the actual acquiring order will be exaclty the same since acquiring a monitor from inside its mutual exclusion is a no-op. This means that even if the data and the actual control flow are the same using both methods, the behavior of the \texttt{wait} will be different. The alternative is option 2, that is releasing \underline{actually} acquired monitors. This solves the issue of having the two acquiring method differ at the cost of making routine \texttt{foo} behave differently depending on from which context it is called (Context 1 or 2). Indeed in Context 2, routine \texttt{foo} will actually behave like routine \texttt{baz} rather than having the same behavior than in context 1. The fact that both implicit approaches can be unintuitive depending on the perspective may be a sign that the explicit approach is superior.
     333This is not intuitive because even if both methods will display the same monitors state both inside and outside the critical section respectively, the behavior is different. Furthermore, the actual acquiring order will be exaclty the same since acquiring a monitor from inside its mutual exclusion is a no-op. This means that even if the data and the actual control flow are the same using both methods, the behavior of the \code{wait} will be different. The alternative is option 2, that is releasing \underline{actually} acquired monitors. This solves the issue of having the two acquiring method differ at the cost of making routine \code{foo} behave differently depending on from which context it is called (Context 1 or 2). Indeed in Context 2, routine \code{foo} will actually behave like routine \code{baz} rather than having the same behavior than in context 1. The fact that both implicit approaches can be unintuitive depending on the perspective may be a sign that the explicit approach is superior.
    311334\\
    312335
    … …  
    314337\\
    315338
     339\begin{center}
    316340\begin{tabular}{|c|c|c|}
    317341Case 1 & Case 2 & Case 3 \\
    … …  
    319343\hline
    320344\begin{lstlisting}
    321 void foo(monitor& mutex a,
    322          monitor& mutex b,
    323            condition& c)
     345void foo(monitor & mutex a,
     346         monitor & mutex b,
     347           condition & c)
    324348{
    325349        // Releases monitors
    326         // branded on construction
     350        // branded in ctor
    327351        wait(c);
    328352}
    … …  
    338362//Will release a and b
    339363foo(a,b,c2);
    340 \end{lstlisting}&\begin{lstlisting}
    341 void foo(monitor& mutex a,
    342          monitor& mutex b,
    343            condition& c)
     364\end{lstlisting} &\begin{lstlisting}
     365void foo(monitor & mutex a,
     366         monitor & mutex b,
     367           condition & c)
    344368{
    345369        // Releases monitor a
    … …  
    358382
    359383
    360 \end{lstlisting}&\begin{lstlisting}
    361 void foo(monitor& mutex a,
    362          monitor& mutex b,
    363            condition& c)
     384\end{lstlisting} &\begin{lstlisting}
     385void foo(monitor & mutex a,
     386         monitor & mutex b,
     387           condition & c)
    364388{
    365389        // Releases monitor a
    … …  
    380404\end{lstlisting}
    381405\end{tabular}
    382 
     406\end{center}
    383407(Note : Case 2 and 3 use tuple semantics to pass a variable length list of elements.)
    384408\\
    385409
    386 All these cases have there pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition was initialized as well as where it is used. On the other hand, it is very clear and explicit which monitor will be released and which monitor will stay acquired. This is similar to Case 2, which releases only the monitors explictly listed. However, in Case 2, calling the \texttt{wait} routine instead of the \texttt{waitRelease} routine will release all the acquired monitor. The Case 3 is an improvement on that since it releases all the monitors except those specified. The result is that the \texttt{wait} routine can be written as follows :
    387 \begin{lstlisting}
    388 void wait(condition& cond) {
     410All these cases have there pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition was initialized as well as where it is used. On the other hand, it is very clear and explicit which monitor will be released and which monitor will stay acquired. This is similar to Case 2, which releases only the monitors explictly listed. However, in Case 2, calling the \code{wait} routine instead of the \code{waitRelease} routine will release all the acquired monitor. The Case 3 is an improvement on that since it releases all the monitors except those specified. The result is that the \code{wait} routine can be written as follows :
     411\begin{lstlisting}
     412void wait(condition & cond) {
    389413        waitHold(cond, []);
    390414}
    391415\end{lstlisting}
    392 This alternative offers nice and consistent behavior between \texttt{wait} and \texttt{waitHold}. However, one large pitfall is that mutual exclusion can now be violated by calls to library code. Indeed, even if the following example seems benign there is one significant problem :
     416This alternative offers nice and consistent behavior between \code{wait} and \code{waitHold}. However, one large pitfall is that mutual exclusion can now be violated by calls to library code. Indeed, even if the following example seems benign there is one significant problem :
    393417\begin{lstlisting}
    394418extern void doStuff();
    395419
    396 void foo(monitor& mutex m) {
     420void foo(monitor & mutex m) {
    397421        //...
    398422        doStuff(); //warning can release monitor m
    … …  
    400424}
    401425\end{lstlisting}
    402 Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of calling code by issuing calls to \texttt{wait} or \texttt{waitHold} in a nested monitor context. Case 2 can be salvaged by removing the \texttt{wait} routine from the API but Case 3 cannot prevent users from calling \texttt{waitHold(someCondition, [])}. For this reason the syntax proposed in Case 3 is rejected. Note that syntaxes proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition as follows both cases can be supported :
     426
     427Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of calling code by issuing calls to \code{wait} or \code{waitHold} in a nested monitor context. Case 2 can be salvaged by removing the \code{wait} routine from the API but Case 3 cannot prevent users from calling \code{waitHold(someCondition, [])}. For this reason the syntax proposed in Case 3 is rejected. Note that syntaxes proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition as follows both cases can be supported :
    403428\begin{lstlisting}
    404429struct condition { /*...*/ };
    405430
    406 void wait(condition& cond, [...] monitorsToRelease); // Second argument is a variable length tuple.
    407 void signal(condition& cond);
     431// Second argument is a variable length tuple.
     432void wait(condition & cond, [...] monitorsToRelease);
     433void signal(condition & cond);
    408434
    409435struct conditionN { /*...*/ };
    410436
    411437void ?{}(conditionN* this, /*list of N monitors to release*/);
    412 void wait(conditionN& cond);
    413 void signal(conditionN& cond);
    414 \end{lstlisting}
    415 
    416 Regardless of the option chosen for wait semantics, signal must be symmetrical. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \texttt{signal} needs to be called from the same monitor(s) than the call to \texttt{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
    417 
    418 \subsection{External scheduling}
     438void wait(conditionN & cond);
     439void signal(conditionN & cond);
     440\end{lstlisting}
     441
     442Regardless of the option chosen for wait semantics, signal must be symmetrical. 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) than the call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
     443
     444\subsection{External scheduling} \label{extsched}
     445\textbf{\large{Work in progress...}}
    419446As one might expect, the alternative to Internal scheduling is to use external scheduling instead. The goal of external scheduling is to be able to have the same scheduling power as internal scheduling without the requirement that any thread can acquire the monitor lock. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. External scheduling can generally be done either in terms of control flow (see \uC) or in terms of data (see Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the reset of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling which is loose object definitions and multi-monitor routines.
    420447
    … …  
    435462        mutex struct A {};
    436463
    437         void f(A& mutex a) { accept(g); }
    438         void g(A& mutex a);
    439 \end{lstlisting}
    440 
    441 While this is the direct translation of the \uC code, at the time of compiling routine \texttt{f} the \CFA does not already have a declaration of \texttt{g} while the \uC compiler does. This means that either the compiler has to dynamically find which routines are "acceptable" or the language needs a way of statically listing "acceptable" routines. Since \CFA has no existing concept that resemble dynamic routine definitions or pattern matching, the static approach seems the more consistent with the current language paradigms. This approach leads to the \uC example being translated to :
    442 \begin{lstlisting}
    443         accept( void g(mutex struct A& mutex a) )
     464        void f(A & mutex a) { accept(g); }
     465        void g(A & mutex a);
     466\end{lstlisting}
     467
     468While this is the direct translation of the \uC code, at the time of compiling routine \code{f} the \CFA does not already have a declaration of \code{g} while the \uC compiler does. This means that either the compiler has to dynamically find which routines are "acceptable" or the language needs a way of statically listing "acceptable" routines. Since \CFA has no existing concept that resemble dynamic routine definitions or pattern matching, the static approach seems the more consistent with the current language paradigms. This approach leads to the \uC example being translated to :
     469\begin{lstlisting}
     470        accept( void g(mutex struct A & mutex a) )
    444471        mutex struct A {};
    445472
    446         void f(A& mutex a) { accept(g); }
    447         void g(A& mutex a);
    448 \end{lstlisting}
    449 
    450 This syntax is the most consistent with the language since it somewhat mimics the \texttt{forall} declarations. However, the fact that it comes before the struct declaration does means the type needs to be forward declared (done inline in the example). Here are a few alternatives to this syntax : \\
     473        void f(A & mutex a) { accept(g); }
     474        void g(A & mutex a);
     475\end{lstlisting}
     476
     477This syntax is the most consistent with the language since it somewhat mimics the \code{forall} declarations. However, the fact that it comes before the struct declaration does means the type needs to be forward declared (done inline in the example). Here are a few alternatives to this syntax : \\
    451478\begin{tabular}[t]{l l}
    452479Alternative 1 & Alternative 2 \\
    453480\begin{lstlisting}
    454481mutex struct A
    455 accept( void g(A& mutex a) )
     482accept( void g(A & mutex a) )
    456483{};
    457 \end{lstlisting}&\begin{lstlisting}
     484\end{lstlisting} &\begin{lstlisting}
    458485mutex struct A {}
    459 accept( void g(A& mutex a) );
     486accept( void g(A & mutex a) );
    460487
    461488\end{lstlisting} \\
    … …  
    463490\begin{lstlisting}
    464491mutex struct A {
    465         accept( void g(A& mutex a) )
     492        accept( void g(A & mutex a) )
    466493};
    467494
    468 \end{lstlisting}&\begin{lstlisting}
     495\end{lstlisting} &\begin{lstlisting}
    469496mutex struct A {
    470497        accept :
    471                 void g(A& mutex a) );
     498                void g(A & mutex a) );
    472499};
    473500\end{lstlisting}
    … …  
    481508External scheduling, like internal scheduling, becomes orders of magnitude more complex when we start introducing multi-monitor syntax. Even in the simplest possible case some new semantics need to be established :
    482509\begin{lstlisting}
    483         accept( void f(mutex struct A& mutex this))
     510        accept( void f(mutex struct A & mutex this))
    484511        mutex struct A {};
    485512
    486513        mutex struct B {};
    487514
    488         void g(A& mutex a, B& mutex b) {
     515        void g(A & mutex a, B & mutex b) {
    489516                accept(f); //ambiguous, which monitor
    490517        }
    … …  
    494521
    495522\begin{lstlisting}
    496         accept( void f(mutex struct A& mutex this))
     523        accept( void f(mutex struct A & mutex this))
    497524        mutex struct A {};
    498525
    499526        mutex struct B {};
    500527
    501         void g(A& mutex a, B& mutex b) {
     528        void g(A & mutex a, B & mutex b) {
    502529                accept( f, b );
    503530        }
    504531\end{lstlisting}
    505532
    506 This is unambiguous. The both locks will be acquired and kept, when routine \texttt{f} is called the lock for monitor \texttt{a} will be temporarily transferred from \texttt{g} to \texttt{f} (while \texttt{g} still holds lock \texttt{b}). This behavior can be extended to multi-monitor accept statment as follows.
    507 
    508 \begin{lstlisting}
    509         accept( void f(mutex struct A& mutex, mutex struct A& mutex))
     533This is unambiguous. The both locks will be acquired and kept, when routine \code{f} is called the lock for monitor \code{a} will be temporarily transferred from \code{g} to \code{f} (while \code{g} still holds lock \code{b}). This behavior can be extended to multi-monitor accept statment as follows.
     534
     535\begin{lstlisting}
     536        accept( void f(mutex struct A & mutex, mutex struct A & mutex))
    510537        mutex struct A {};
    511538
    512539        mutex struct B {};
    513540
    514         void g(A& mutex a, B& mutex b) {
     541        void g(A & mutex a, B & mutex b) {
    515542                accept( f, b, a );
    516543        }
    517544\end{lstlisting}
    518545
    519 Note that the set of monitors passed to the \texttt{accept} statement must be entirely contained in the set of monitor already acquired in the routine. \texttt{accept} used in any other context is Undefined Behaviour.
     546Note that the set of monitors passed to the \code{accept} statement must be entirely contained in the set of monitor already acquired in the routine. \code{accept} used in any other context is Undefined Behaviour.
    520547
    521548\subsection{Implementation Details}
     549\textbf{\large{Work in progress...}}
    522550\subsubsection{Interaction with polymorphism}
    523551At first glance, interaction between monitors and \CFA's concept of polymorphism seem complexe to support. However, it can be reasoned that entry-point locking can solve most of the issues that could be present with polymorphism.
    524552
    525 First of all, interaction between \texttt{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore the main question is how to support \texttt{dtype} polymorphism. We must remember that monitors' 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 \texttt{dtype} polymorphism always handle incomplete types (by definition) no \texttt{dtype} polymorphic routine can access shared data since the data would require knowledge about the type. Therefore the only concern when combining \texttt{dtype} polymorphism and monitors is to protect access to routines. With callsite-locking, this would require significant amount of work since any \texttt{dtype} routine could have to obtain some lock before calling a routine. However, with entry-point-locking calling a monitor routine becomes exactly the same as calling it from anywhere else.
     553First 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. We must remember that monitors' 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 handle incomplete types (by definition) no \code{dtype} polymorphic routine can access shared data since the data would require knowledge about the type. Therefore the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. With callsite-locking, this would require significant amount of work since any \code{dtype} routine could have to obtain some lock before calling a routine. However, with entry-point-locking calling a monitor routine becomes exactly the same as calling it from anywhere else.
    526554
    527555\subsubsection{External scheduling queues}
    … …  
    532560\section{Tasks}
    533561
    534 
    535562\section{Naming}
    536563
Note: See TracChangeset for help on using the changeset viewer.