Index: doc/proposals/concurrency/.gitignore =================================================================== --- doc/proposals/concurrency/.gitignore (revision a3eaa2920696cf493afb9095f0a2361e686d5225) +++ doc/proposals/concurrency/.gitignore (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -18,2 +18,4 @@ concurrency.ps version.aux +monitor.tex +ext_monitor.tex Index: doc/proposals/concurrency/Makefile =================================================================== --- doc/proposals/concurrency/Makefile (revision a3eaa2920696cf493afb9095f0a2361e686d5225) +++ doc/proposals/concurrency/Makefile (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -12,4 +12,6 @@ FIGURES = ${addsuffix .tex, \ + monitor \ + ext_monitor \ } @@ -32,5 +34,5 @@ clean : - rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t *.cf *.glg *.glo *.gls *.ist \ + rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t *.cf *.glg *.glo *.gls *.ist *.acn *.acr *.alg \ ${FIGURES} ${PICTURES} ${PROGRAMS} ${GRAPHS} ${basename ${DOCUMENT}}.ps ${DOCUMENT} Index: doc/proposals/concurrency/concurrency.tex =================================================================== --- doc/proposals/concurrency/concurrency.tex (revision a3eaa2920696cf493afb9095f0a2361e686d5225) +++ doc/proposals/concurrency/concurrency.tex (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -1,10 +1,10 @@ % requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended -% inline code �...� (copyright symbol) emacs: C-q M-) -% red highlighting �...� (registered trademark symbol) emacs: C-q M-. -% blue highlighting �...� (sharp s symbol) emacs: C-q M-_ -% green highlighting �...� (cent symbol) emacs: C-q M-" -% LaTex escape �...� (section symbol) emacs: C-q M-' -% keyword escape �...� (pilcrow symbol) emacs: C-q M-^ +% inline code ©...© (copyright symbol) emacs: C-q M-) +% red highlighting ®...® (registered trademark symbol) emacs: C-q M-. +% blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_ +% green highlighting ¢...¢ (cent symbol) emacs: C-q M-" +% LaTex escape §...§ (section symbol) emacs: C-q M-' +% keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^ % math escape $...$ (dollar symbol) @@ -101,5 +101,5 @@ Finally, an approach that is worth mentionning because it is gaining in popularity is transactionnal memory\cite{Dice10}. 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. -\section{Monitors} +\subsection{Monitors} 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\cite{Java} or \uC\cite{uC++book} but does not strictly require OOP semantics. The only requirements is the ability to declare a handle to a shared object and a set of routines that act on it : \begin{lstlisting} @@ -113,5 +113,5 @@ \end{lstlisting} -\subsection{Call semantics} \label{call} +\subsubsection{Call semantics} \label{call} The 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 at their core, monitors are implicit mutual exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable. \\ @@ -147,5 +147,5 @@ The problem is to indentify which object(s) should be acquired. Furthermore we also need to acquire each objects 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 will be acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths aren't 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 custom 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). -\subsection{Data semantics} \label{data} +\subsubsection{Data semantics} \label{data} 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}: \begin{lstlisting} @@ -217,4 +217,9 @@ Recursive mutex routine calls are allowed in \CFA but if not done carefully it can lead to nested monitor call problems\cite{Lister77}. These problems 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{bar} but explicit ordering in the case of \code{baz}. This subtle mistake can mean that calling these two functions concurrently will lead to deadlocks, depending on the implicit ordering matching the explicit ordering. As shown on several occasion\cit, there isn't really any solutions to this problem, users simply need to be carefull when acquiring multiple monitors at the same time. + +\subsubsection{Implementation Details: Interaction with polymorphism} +At 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. + +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. 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. \subsection{Internal scheduling} \label{insched} @@ -462,5 +467,5 @@ \subsection{External scheduling} \label{extsched} -As one might expect, the alternative to Internal scheduling is to use External scheduling instead. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. Indeed, as the following examples will demontrate, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. 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 whith loose object definitions and multi-monitor routines. The following example shows what a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages. +As one might expect, the alternative to Internal scheduling is to use External scheduling instead. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. Indeed, as the following examples will demonstrate, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (ex: \uC) or in terms of data (ex: 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 rest of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multi-monitor routines. The following example shows what a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages. \begin{center} @@ -472,7 +477,6 @@ condition c; public: - void f(); - void g() { signal} - void h() { wait(c); } + void f() { signal(c)} + void g() { wait(c); } private: } @@ -482,6 +486,5 @@ public: void f(); - void g(); - void h() { _Accept(g); } + void g() { _Accept(f); } private: } @@ -500,9 +503,34 @@ void f(A & mutex a); - void g(A & mutex a); - void h(A & mutex a) { accept(g); } -\end{lstlisting} - -While 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 : + void g(A & mutex a) { accept(f); } +\end{lstlisting} + +However, external scheduling is an example where implementation constraints become visible from the interface. Indeed, ince there is no hard limit to the number of threads trying to acquire a monitor concurrently, performance is a significant concern. Here is the pseudo code for the entering phase of a monitor : + +\begin{center} +\begin{tabular}{l} +\begin{lstlisting} + ¶if¶ critical section is free : + enter + elif critical section accepts me : + enter + ¶else¶ : + block +\end{lstlisting} +\end{tabular} +\end{center} + +For the \code{critical section is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \code{critical section accepts me} is much harder to implement depending on the constraints put on the monitors. Indeed, monitors are often expressed as an entry queue and some acceptor queue as in the following figure : + +\begin{center} +{\resizebox{0.5\textwidth}{!}{\input{monitor}}} +\end{center} + +There are other alternatives to these pictures but in the case of this picture implementing a fast accept check is relatively easy. Indeed simply updating a bitmask when the acceptor queue changes is enough to have a check that executes in a single instruction, even with a fairly large number of acceptor. However, this requires all the acceptable routines to be declared with the monitor declaration. For OO languages this doesn't compromise much since monitors already have an exhaustive list of member routines. However, for \CFA this isn't the case, routines can be added to a type anywhere after its declaration. A more flexible + + +At this point we must make a decision between flexibility and performance. Many design decisions in \CFA achieve both flexibility and performance, for example polymorphic routines add significant flexibility but inlining them means the optimizer can easily remove any runtime cost. + +This approach leads to the \uC example being translated to : \begin{lstlisting} accept( void g(mutex struct A & mutex a) ) @@ -584,12 +612,5 @@ Note 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. -\subsection{Implementation Details} -\textbf{\large{Work in progress...}} -\subsubsection{Interaction with polymorphism} -At 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. - -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. 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. - -\subsubsection{External scheduling queues} +\subsubsection{Implementation Details: External scheduling queues} To support multi-monitor external scheduling means that some kind of entry-queues must be used that is aware of both monitors. However, acceptable routines must be aware of the entry queues which means they most be stored inside at least one of the monitors that will be acquired. This in turn adds the requirement a systematic algorithm of disambiguating which queue is relavant regardless of user ordering. The proposed algorithm is to fall back on monitors lock ordering and specify that the monitor that is acquired first is the lock with the relevant entry queue. This assumes that the lock acquiring order is static for the lifetime of all concerned objects gut that is a reasonnable contraint. This algorithm choice has two consequences, the ofthe highest priority monitor is no longer a true FIFO queue and the queue of the lowest priority monitor is both required and probably unused. The queue can no longer be a FIFO queue because instead of simply containing the waiting threads in order arrival, they also contain the second mutex. Therefore, another thread with the same highest priority monitor but a different lowest priority monitor may arrive first but enter the critical section after a thread with the correct pairing. Secondly, since it may not be known at compile time which monitor will be the lowest priority monitor, every monitor needs to have the correct queues even though it is probably that half the multi-monitor queues will go unused for the entire duration of the program. Index: doc/proposals/concurrency/ext_monitor.fig =================================================================== --- doc/proposals/concurrency/ext_monitor.fig (revision 90592137ba64a318983658fd3c7acaa5e30676c6) +++ doc/proposals/concurrency/ext_monitor.fig (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -0,0 +1,118 @@ +#FIG 3.2 Produced by xfig version 3.2.5c +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 1275 1200 1575 1500 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 1425 1350 105 105 1425 1350 1530 1350 +4 1 -1 0 0 0 10 0.0000 2 105 90 1425 1410 b\001 +-6 +6 1275 1500 1575 1800 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 1425 1650 105 105 1425 1650 1530 1650 +4 1 -1 0 0 0 10 0.0000 2 75 75 1425 1695 a\001 +-6 +6 2175 1500 2475 1800 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2325 1650 105 105 2325 1650 2430 1650 +4 1 -1 0 0 0 10 0.0000 2 75 75 2325 1695 c\001 +-6 +6 2175 1200 2475 1500 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2325 1350 105 105 2325 1350 2430 1350 +4 1 -1 0 0 0 10 0.0000 2 105 90 2325 1410 d\001 +-6 +6 2775 1200 7350 5700 +5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 3450.000 3150 3150 2850 3450 3150 3750 +5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 3150.000 4350.000 3150 4050 2850 4350 3150 4650 +6 5850 1950 6150 2250 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2100 105 105 6000 2100 6105 2205 +4 1 -1 0 0 0 10 0.0000 2 105 90 6000 2160 d\001 +-6 +6 5850 1650 6150 1950 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 1800 105 105 6000 1800 6105 1905 +4 1 -1 0 0 0 10 0.0000 2 105 90 6000 1860 b\001 +-6 +6 3000 5400 6975 5700 +1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3150 5550 80 80 3150 5550 3230 5630 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4500 5550 105 105 4500 5550 4605 5655 +1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 6000 5550 105 105 6000 5550 6105 5655 +4 0 -1 0 0 0 12 0.0000 2 180 765 6225 5625 duplicate\001 +4 0 -1 0 0 0 12 0.0000 2 135 1035 4725 5625 blocked task\001 +4 0 -1 0 0 0 12 0.0000 2 135 870 3300 5625 active task\001 +-6 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3300 3600 105 105 3300 3600 3405 3705 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3600 3600 105 105 3600 3600 3705 3705 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6600 3900 105 105 6600 3900 6705 4005 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6900 3900 105 105 6900 3900 7005 4005 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2700 105 105 6000 2700 6105 2805 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6000 2400 105 105 6000 2400 6105 2505 +1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 5100 4575 80 80 5100 4575 5180 4655 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 5850 2850 6075 3000 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 3150 3750 3750 3750 3750 4050 3150 4050 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3 + 3150 3450 3750 3450 3900 3675 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 3750 3150 3600 3375 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3 + 3150 4350 3750 4350 3900 4575 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 3750 4050 3600 4275 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 3150 4650 3750 4650 3750 4950 4950 4950 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 6450 3750 6300 3975 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 4950 4950 5175 5100 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9 + 5250 4950 6450 4950 6450 4050 7050 4050 7050 3750 6450 3750 + 6450 2850 6150 2850 6150 1650 +2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5 + 5850 4200 5850 3300 4350 3300 4350 4200 5850 4200 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3 + 5250 2850 5850 2850 5850 1650 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 3150 3150 3750 3150 3750 2850 5325 2850 +4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2745 a\001 +4 1 -1 0 0 0 10 0.0000 2 75 75 6000 2445 c\001 +4 1 -1 0 0 0 12 0.0000 2 135 315 5100 5325 exit\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 3300 3075 A\001 +4 1 -1 0 0 0 12 0.0000 2 135 795 3300 4875 condition\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 3300 5100 B\001 +4 0 -1 0 0 0 12 0.0000 2 135 420 6600 3675 stack\001 +4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3225 acceptor/\001 +4 0 -1 0 0 0 12 0.0000 2 180 750 6600 3450 signalled\001 +4 1 -1 0 0 0 12 0.0000 2 135 795 3300 2850 condition\001 +4 1 -1 0 0 0 12 0.0000 2 165 420 6000 1350 entry\001 +4 1 -1 0 0 0 12 0.0000 2 135 495 6000 1575 queue\001 +4 0 -1 0 0 0 12 0.0000 2 135 525 6300 2400 arrival\001 +4 0 -1 0 0 0 12 0.0000 2 135 630 6300 2175 order of\001 +4 1 -1 0 0 0 12 0.0000 2 135 525 5100 3675 shared\001 +4 1 -1 0 0 0 12 0.0000 2 135 735 5100 3975 variables\001 +-6 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 1275 1800 1500 1950 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 2175 1800 2400 1950 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 1575 1200 1575 1800 2175 1800 2175 1200 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4 + 1275 1200 1275 2100 2475 2100 2475 1200 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4050 2925 5475 2925 5475 3225 4050 3225 4050 2925 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 1875 2400 1875 2175 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2 + 7 1 1.00 60.00 120.00 + 5250 3075 5250 2400 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 5250 2400 1875 2400 +4 1 -1 0 0 0 12 0.0000 2 135 135 2325 1125 Y\001 +4 1 -1 0 0 0 12 0.0000 2 120 510 1875 675 mutex\001 +4 1 -1 0 0 0 12 0.0000 2 135 570 1875 900 queues\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 1425 1125 X\001 +4 0 0 50 -1 0 11 0.0000 2 150 795 4275 3150 Queues Ptr\001 Index: doc/proposals/concurrency/monitor.fig =================================================================== --- doc/proposals/concurrency/monitor.fig (revision 90592137ba64a318983658fd3c7acaa5e30676c6) +++ doc/proposals/concurrency/monitor.fig (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -0,0 +1,101 @@ +#FIG 3.2 Produced by xfig version 3.2.5c +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 2700.000 1500 2400 1200 2700 1500 3000 +5 1 0 1 -1 -1 0 0 -1 0.000 0 1 0 0 1500.000 3600.000 1500 3300 1200 3600 1500 3900 +6 4200 1200 4500 1500 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1350 105 105 4350 1350 4455 1455 +4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1410 d\001 +-6 +6 4200 900 4500 1200 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1050 105 105 4350 1050 4455 1155 +4 1 -1 0 0 0 10 0.0000 2 105 90 4350 1110 b\001 +-6 +6 2400 1500 2700 1800 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1650 105 105 2550 1650 2655 1650 +4 1 -1 0 0 0 10 0.0000 2 105 90 2550 1710 b\001 +-6 +6 2400 1800 2700 2100 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 2550 1950 105 105 2550 1950 2655 1950 +4 1 -1 0 0 0 10 0.0000 2 75 75 2550 1995 a\001 +-6 +6 3300 1500 3600 1800 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1650 105 105 3450 1650 3555 1650 +4 1 -1 0 0 0 10 0.0000 2 105 90 3450 1710 d\001 +-6 +6 1350 4650 5325 4950 +1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 1500 4800 80 80 1500 4800 1580 4880 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2850 4800 105 105 2850 4800 2955 4905 +1 3 0 1 -1 -1 0 0 4 0.000 1 0.0000 4350 4800 105 105 4350 4800 4455 4905 +4 0 -1 0 0 0 12 0.0000 2 180 765 4575 4875 duplicate\001 +4 0 -1 0 0 0 12 0.0000 2 135 1035 3075 4875 blocked task\001 +4 0 -1 0 0 0 12 0.0000 2 135 870 1650 4875 active task\001 +-6 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1650 2850 105 105 1650 2850 1755 2955 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 1950 2850 105 105 1950 2850 2055 2955 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 3150 105 105 4950 3150 5055 3255 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5250 3150 105 105 5250 3150 5355 3255 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1950 105 105 4350 1950 4455 2055 +1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4350 1650 105 105 4350 1650 4455 1755 +1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3450 3825 80 80 3450 3825 3530 3905 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 3450 1950 105 105 3450 1950 3555 1950 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 2400 2100 2625 2250 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 3300 2100 3525 2250 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 4200 2100 4425 2250 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 5 + 1500 2400 2100 2400 2100 2100 2400 2100 2400 1500 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 1500 3000 2100 3000 2100 3300 1500 3300 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3 + 1500 2700 2100 2700 2250 2925 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 2100 2400 1950 2625 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 3 + 1500 3600 2100 3600 2250 3825 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 2100 3300 1950 3525 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 1500 3900 2100 3900 2100 4200 3300 4200 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 4800 3000 4650 3225 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 + 3300 4200 3525 4350 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 3600 1500 3600 2100 4200 2100 4200 900 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 4 + 2700 1500 2700 2100 3300 2100 3300 1500 +2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 9 + 3600 4200 4800 4200 4800 3300 5400 3300 5400 3000 4800 3000 + 4800 2100 4500 2100 4500 900 +2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5 + 4200 3450 4200 2550 2700 2550 2700 3450 4200 3450 +4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1995 a\001 +4 1 -1 0 0 0 10 0.0000 2 75 75 4350 1695 c\001 +4 1 -1 0 0 0 12 0.0000 2 135 315 3450 4575 exit\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 1650 2325 A\001 +4 1 -1 0 0 0 12 0.0000 2 135 795 1650 4125 condition\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 1650 4350 B\001 +4 0 -1 0 0 0 12 0.0000 2 135 420 4950 2925 stack\001 +4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2475 acceptor/\001 +4 0 -1 0 0 0 12 0.0000 2 180 750 4950 2700 signalled\001 +4 1 -1 0 0 0 12 0.0000 2 135 795 1650 2100 condition\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 2550 1425 X\001 +4 1 -1 0 0 0 12 0.0000 2 135 135 3450 1425 Y\001 +4 1 -1 0 0 0 12 0.0000 2 165 420 4350 600 entry\001 +4 1 -1 0 0 0 12 0.0000 2 135 495 4350 825 queue\001 +4 0 -1 0 0 0 12 0.0000 2 135 525 4650 1650 arrival\001 +4 0 -1 0 0 0 12 0.0000 2 135 630 4650 1425 order of\001 +4 1 -1 0 0 0 12 0.0000 2 135 525 3450 2925 shared\001 +4 1 -1 0 0 0 12 0.0000 2 135 735 3450 3225 variables\001 +4 1 -1 0 0 0 12 0.0000 2 120 510 3000 975 mutex\001 +4 1 -1 0 0 0 10 0.0000 2 75 75 3450 1995 c\001 +4 1 -1 0 0 0 12 0.0000 2 135 570 3000 1200 queues\001 Index: doc/proposals/concurrency/version =================================================================== --- doc/proposals/concurrency/version (revision a3eaa2920696cf493afb9095f0a2361e686d5225) +++ doc/proposals/concurrency/version (revision 90592137ba64a318983658fd3c7acaa5e30676c6) @@ -1,1 +1,1 @@ -0.4.22 +0.4.61