Index: doc/LaTeXmacros/common.tex =================================================================== --- doc/LaTeXmacros/common.tex (revision c2183a3e0a8e3d9af49d0a4adad59edcd0b48c36) +++ doc/LaTeXmacros/common.tex (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) @@ -228,4 +228,41 @@ % CFA programming language, based on ANSI C (with some gcc additions) +\lstdefinelanguage{Pseudo}{ + morekeywords={string,uint,int,bool,float},% + sensitive=true,% + morecomment=[l]{//},% + morecomment=[s]{/*}{*/},% + morestring=[b]',% + morestring=[b]",% + morestring=[s]{`}{`},% +}% + +\lstset{ +language=Pseudo, +columns=fullflexible, +basicstyle=\linespread{0.9}\tt\small, % reduce line spacing and use typewriter font +stringstyle=\sf\color{Mahogany}, % use sanserif font +commentstyle=\itshape\color{OliveGreen}, % green and italic comments +tabsize=4, % 4 space tabbing +xleftmargin=\parindentlnth, % indent code to paragraph indentation +extendedchars=true, % allow ASCII characters in the range 128-255 +escapechar=§, % escape to latex in CFA code +mathescape=true, % allow $...$ LaTeX math escapes in code +%keepspaces=true, % +showstringspaces=false, % do not show spaces with cup +showlines=true, % show blank lines at end of code +aboveskip=4pt, % spacing above/below code block +belowskip=3pt, +moredelim=**[is][\color{red}]{®}{®}, % red highlighting +moredelim=**[is][\color{blue}]{ß}{ß}, % blue highlighting +moredelim=**[is][\color{OliveGreen}]{¢}{¢}, % green highlighting +moredelim=[is][\lstset{keywords={}}]{¶}{¶}, % temporarily turn off keywords +% replace/adjust listing characters that look bad in sanserif +literate={-}{\raisebox{-0.15ex}{\texttt{-}}}1 {^}{\raisebox{0.6ex}{$\scriptscriptstyle\land\,$}}1 {©}{{\"u}}1 + {~}{\raisebox{0.3ex}{$\scriptstyle\sim\,$}}1 {_}{\makebox[1.2ex][c]{\rule{1ex}{0.1ex}}}1 {`}{\ttfamily\upshape\hspace*{-0.1ex}`}1 + {<-}{$\leftarrow$}2 {=>}{$\Rightarrow$}2, +}% + +% CFA programming language, based on ANSI C (with some gcc additions) \lstdefinelanguage{CFA}[ANSI]{C}{ morekeywords=[1]{_Alignas,_Alignof,__alignof,__alignof__,asm,__asm,__asm__,_At,_Atomic,__attribute,__attribute__,auto, @@ -265,4 +302,5 @@ \lstMakeShortInline© % single-character for \lstinline + \let\Oldthebibliography\thebibliography \renewcommand\thebibliography[1]{ Index: doc/proposals/concurrency/concurrency.tex =================================================================== --- doc/proposals/concurrency/concurrency.tex (revision c2183a3e0a8e3d9af49d0a4adad59edcd0b48c36) +++ doc/proposals/concurrency/concurrency.tex (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) @@ -62,4 +62,5 @@ \newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace} \newcommand{\code}[1]{\lstinline{#1}} +\newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}} \input{glossary} @@ -510,10 +511,10 @@ \begin{center} \begin{tabular}{l} -\begin{lstlisting} - ¶if¶ critical section is free : +\begin{lstlisting}[language=Pseudo] + if monitor is free : enter - elif critical section accepts me : + elif monitor accepts me : enter - ¶else¶ : + else : block \end{lstlisting} @@ -521,34 +522,36 @@ \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) ) - mutex struct A {}; - - void f(A & mutex a) { accept(g); } - void g(A & mutex a); -\end{lstlisting} - -This 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 : \\ -\begin{tabular}[t]{l l} +For the \pseudo{monitor is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \pseudo{monitor 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.4\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 relies on the fact that all the acceptable routines are declared with the monitor type. 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. Its important to note that the bitmask approach does not actually require an exhaustive list of routines, but it requires a dense unique ordering of routines with an upper-bound and that ordering must be consistent across translation units. +The alternative would be to have a picture more like this one: + +\begin{center} +{\resizebox{0.4\textwidth}{!}{\input{ext_monitor}}} +\end{center} + +Not storing the queues inside the monitor means that the storage can vary between routines, allowing for more flexibility and extensions. Storing an array of function-pointers would solve the issue of uniquely identifying acceptable routines. However, the single instruction bitmask compare has been replaced by dereferencing a pointer followed by a linear search. Furthermore, supporting nested external scheduling may now require additionnal searches on calls to accept to check if a routine is already queued in. + +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. Here however, the cost of flexibility cannot be trivially removed. + +In either cases here are a few alternatives for the different syntaxes this syntax : \\ +\begin{center} +{\renewcommand{\arraystretch}{1.5} +\begin{tabular}[t]{l @{\hskip 0.35in} l} +\hline +\multicolumn{2}{ c }{\code{accept} on type}\\ +\hline Alternative 1 & Alternative 2 \\ \begin{lstlisting} mutex struct A -accept( void g(A & mutex a) ) +accept( void f(A & mutex a) ) {}; \end{lstlisting} &\begin{lstlisting} mutex struct A {} -accept( void g(A & mutex a) ); +accept( void f(A & mutex a) ); \end{lstlisting} \\ @@ -556,5 +559,5 @@ \begin{lstlisting} mutex struct A { - accept( void g(A & mutex a) ) + accept( void f(A & mutex a) ) }; @@ -562,9 +565,23 @@ mutex struct A { accept : - void g(A & mutex a) ); + void f(A & mutex a) ); }; -\end{lstlisting} +\end{lstlisting}\\ +\hline +\multicolumn{2}{ c }{\code{accept} on routine}\\ +\hline +\begin{lstlisting} +mutex struct A {}; + +void f(A & mutex a) + +accept( void f(A & mutex a) ) +void g(A & mutex a) { + /*...*/ +} +\end{lstlisting}&\\ \end{tabular} - +} +\end{center} An other aspect to consider is what happens if multiple overloads of the same routine are used. For the time being it is assumed that multiple overloads of the same routine should be scheduled regardless of the overload used. However, this could easily be extended in the future. @@ -597,5 +614,5 @@ \end{lstlisting} -This 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. +This is unambiguous. 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. \begin{lstlisting} @@ -613,7 +630,8 @@ \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. +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 must 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 but that is a reasonnable constraint. This algorithm choice has two consequences, the entry queue of the 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 probable that half the multi-monitor queues will go unused for the entire duration of the program. \subsection{Other concurrency tools} +TO BE CONTINUED... \section{Parallelism} Index: doc/proposals/concurrency/ext_monitor.fig =================================================================== --- doc/proposals/concurrency/ext_monitor.fig (revision c2183a3e0a8e3d9af49d0a4adad59edcd0b48c36) +++ doc/proposals/concurrency/ext_monitor.fig (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) @@ -8,21 +8,4 @@ -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 @@ -35,11 +18,19 @@ 4 1 -1 0 0 0 10 0.0000 2 105 90 6000 1860 b\001 -6 -6 3000 5400 6975 5700 +6 5100 1800 5400 2100 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 1950 105 105 5250 1950 5355 1950 +4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2010 Y\001 +-6 +6 5100 2100 5400 2400 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 2250 105 105 5250 2250 5355 2250 +4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2295 X\001 +-6 +6 3000 5400 7200 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 +4 0 -1 0 0 0 12 0.0000 2 180 930 6225 5625 routine ptrs\001 -6 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3300 3600 105 105 3300 3600 3405 3705 @@ -50,4 +41,6 @@ 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 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 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 5850 2850 6075 3000 @@ -77,4 +70,10 @@ 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 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 60.00 120.00 + 7 1 1.00 60.00 120.00 + 5250 3150 5250 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1800 5400 1800 5400 2400 5100 2400 5100 1800 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 @@ -93,26 +92,3 @@ 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 +4 0 0 50 -1 0 11 0.0000 2 165 855 4275 3150 Acceptables\001 Index: doc/proposals/concurrency/ext_monitor.fig.bak =================================================================== --- doc/proposals/concurrency/ext_monitor.fig.bak (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) +++ doc/proposals/concurrency/ext_monitor.fig.bak (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) @@ -0,0 +1,95 @@ +#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 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 5100 1800 5400 2100 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 1950 105 105 5250 1950 5355 1950 +4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2010 Y\001 +-6 +6 5100 2100 5400 2400 +1 3 0 1 -1 -1 1 0 4 0.000 1 0.0000 5250 2250 105 105 5250 2250 5355 2250 +4 1 -1 0 0 0 10 0.0000 2 105 120 5250 2295 X\001 +-6 +6 3000 5400 7200 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 135 1035 4725 5625 blocked task\001 +4 0 -1 0 0 0 12 0.0000 2 135 870 3300 5625 active task\001 +4 0 -1 0 0 0 12 0.0000 2 180 930 6225 5625 routine ptrs\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 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 -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 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2 + 1 1 1.00 60.00 120.00 + 7 1 1.00 60.00 120.00 + 5250 3150 5250 2400 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 5100 1800 5400 1800 5400 2400 5100 2400 5100 1800 +4 0 0 50 -1 0 11 0.0000 2 150 795 4275 3150 Queues Ptr\001 +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 +4 0 0 50 -1 0 11 0.0000 2 165 855 4125 2175 Acceptables\001 Index: doc/proposals/concurrency/version =================================================================== --- doc/proposals/concurrency/version (revision c2183a3e0a8e3d9af49d0a4adad59edcd0b48c36) +++ doc/proposals/concurrency/version (revision b1bdc7d6072e1ce8bc54fea4b46086c9c0f2d299) @@ -1,1 +1,1 @@ -0.4.61 +0.4.88