Index: doc/LaTeXmacros/common.tex =================================================================== --- doc/LaTeXmacros/common.tex (revision 40744af8b1bb93262cbdaa65ccf399c6df297cc7) +++ doc/LaTeXmacros/common.tex (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -1,16 +1,16 @@ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%% -%% +%% %% Cforall Version 1.0.0 Copyright (C) 2016 University of Waterloo %% %% The contents of this file are covered under the licence agreement in the %% file "LICENCE" distributed with Cforall. -%% -%% common.tex -- -%% +%% +%% common.tex -- +%% %% Author : Peter A. Buhr %% Created On : Sat Apr 9 10:06:17 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Sun Aug 14 08:27:29 2016 -%% Update Count : 231 +%% Last Modified On : Tue Oct 25 22:04:19 2016 +%% Update Count : 234 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -41,4 +41,5 @@ \newcommand{\CCeleven}{\rm C\kern-.1em\hbox{+\kern-.25em+}11\xspace} % C++11 symbolic name \newcommand{\Celeven}{C11\xspace} % C11 symbolic name +\newcommand{\Csharp}{C\raisebox{0.4ex}{\#}\xspace} % C# symbolic name %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -226,4 +227,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={_Alignas,_Alignof,__alignof,__alignof__,asm,__asm,__asm__,_At,_Atomic,__attribute,__attribute__,auto, @@ -260,4 +298,5 @@ \lstMakeShortInline© % single-character for \lstinline + \let\Oldthebibliography\thebibliography \renewcommand\thebibliography[1]{ Index: doc/bibliography/cfa.bib =================================================================== --- doc/bibliography/cfa.bib (revision 40744af8b1bb93262cbdaa65ccf399c6df297cc7) +++ doc/bibliography/cfa.bib (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -21,11 +21,20 @@ % tcs: Theoretical Computer Science @string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"} +% @string{ieeepds="IEEE Trans. Parallel Distrib. Syst."} @string{ieeese="IEEE Transactions on Software Engineering"} +% @string{ieeese="IEEE Trans. Softw. Eng."} @string{spe="Software---\-Practice and Experience"} +% @string{spe="Softw. Pract. Exp."} +@string{ccpe="Concurrency and Computation: Practice and Experience"} +% @string{ccpe="Concurrency Comput. Pract. Exp."} @string{sigplan="SIGPLAN Notices"} +% @string{sigplan="SIGPLAN Not."} @string{joop="Journal of Object-Oriented Programming"} +% @string{joop="J. of Object-Oriented Program."} @string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"} @string{osr="Operating Systems Review"} @string{pldi="Programming Language Design and Implementation"} +@string{mathann="Mathematische Annalen"} +% @string{mathann="Math. Ann."} % A @@ -39,4 +48,5 @@ booktitle = {Parallel Programming in {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, publisher = {MIT Press}, + address = {New York}, series = {Scientific and Engineering Computation Series}, year = 1996, @@ -120,6 +130,6 @@ year = 1996, pages = {483-499}, - publisher = {Addison-Wesley Longman Publishing Co., Inc.}, - address = {Boston, MA, USA}, + publisher = {Addison-Wesley Longman Publishing}, + address = {Boston}, } @@ -161,5 +171,5 @@ author = {Gul A. Agha}, title = {Actors: A Model of Concurrent Computation in Distributed Systems}, - publisher = {MIT Press, Cambridge, Mass.}, + publisher = {MIT Press, Cambridge}, year = 1986 } @@ -311,5 +321,5 @@ publisher = {Microsoft Press}, year = 1997, - edition = {third}, + edition = {3rd}, } @@ -325,4 +335,14 @@ year = 1977, pages = {604-605}, +} + +@manual{Akka, + keywords = {Akka actor model}, + contributer = {pabuhr@plg}, + title = {{A}kka {S}cala Documentation, Release 2.4.11}, + organization= {Lightbend Inc.}, + month = sep, + year = 2016, + note = {\href{http://doc.akka.io/docs/akka/2.4/AkkaScala.pdf}{http://\-doc.akka.io/\-docs/\-akka/\-2.4/\-AkkaScala.pdf}}, } @@ -378,6 +398,6 @@ author = {M. Raynal}, title = {Algorithms for Mutual Exclusion}, - publisher = {The MIT Press}, - address = {Cambridge, Massachusetts}, + publisher = {MIT Press}, + address = {Cambridge}, series = {Scientific Computation Series}, year = 1986, @@ -394,4 +414,5 @@ pages = {329-342}, publisher = {Springer}, + address = {New York}, year = 2005, volume = 3669, @@ -404,5 +425,5 @@ editor = {Richard L. Sites}, title = {Alpha Architecture Reference Manual}, - publisher = {Digital Press, One Burlington Woods Drive, Burlington, MA, U. S. A., 01803}, + publisher = {Digital Press, Burlington}, year = 1992, } @@ -413,5 +434,6 @@ editor = {Mary Shaw}, title = {{ALPHARD}: Form and Content}, - publisher = {Springer-Verlag}, + publisher = {Springer}, + address = {New York}, year = 1981, comment = {Collection of papers about Alphard.} @@ -470,4 +492,5 @@ editor = {Gul Agha and Peter Wegner and Akinori Yonezawa}, publisher = {MIT Press}, + address = {New York}, year = 1993, pages = {107-150}, @@ -495,5 +518,5 @@ location = {Toulouse, France}, doi = {http://doi.acm.org/10.1145/318773.319251}, - publisher = {Springer-Verlag}, + publisher = {Springer}, address = {London, UK}, } @@ -504,6 +527,7 @@ title = {The Annotated {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Reference Manual}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1990, - edition = {first}, + edition = {1st}, } @@ -567,6 +591,6 @@ year = 2008, isbn = {0123705916, 9780123705914}, - publisher = {Morgan Kaufmann Publishers Inc.}, - address = {San Francisco, CA, USA}, + publisher = {Morgan Kaufmann Publishers}, + address = {San Francisco}, } @@ -747,4 +771,14 @@ } +@misc{BoostCoroutines15, + keywords = {Boost Coroutine Library}, + contributer = {pabuhr@plg}, + author = {Oliver Kowalke}, + title = {Boost Coroutine Library}, + year = 2015, + note = {\href{http://www.boost.org/doc/libs/1_61_0/libs/coroutine/doc/html/index.html} + {{http://www.boost.org/\-doc/\-libs/1\_61\_0/\-libs/\-coroutine/\-doc/\-html/\-index.html}} [Accessed September 2016]}, +} + @mastersthesis{Krischer02, author = {Roy Krischer }, @@ -779,5 +813,5 @@ editor = {C. Dony and J. L. Knudsen and A. Romanovsky and A. Tripathi}, booktitle = {Advanced Topics in Exception Handling Techniques}, - publisher = {Springer-Verlag}, + publisher = {Springer}, series = {Lecture Notes in Computer Science}, volume = 4119, @@ -793,8 +827,9 @@ author = {Brian W. Kernighan and Dennis M. Ritchie}, title = {The {C} Programming Language}, - publisher = {Prentice Hall}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1988, - edition = {second}, - series = {Prentice Hall Software Series}, + edition = {2nd}, + series = {Prentice-Hall Software Series}, comment = { based on draft-proposed ANSI C @@ -807,7 +842,8 @@ author = {Brian W. Kernighan and Dennis M. Ritchie}, title = {The {C} Programming Language}, - publisher = {Prentice Hall}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1978, - edition = {first}, + edition = {1st}, } @@ -835,12 +871,12 @@ @manual{C++Concepts, - keywords = {ISO/IEC TS 19217:2015}, - contributer = {a3moss@uwaterloo.ca}, - key = {C++ Concepts}, - title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts}, - organization = {International Standard ISO/IEC TS 19217:2015}, - publisher = {International Standard Organization}, - address = {http://www.iso.org}, - year = 2015 + keywords = {ISO/IEC TS 19217:2015}, + contributer = {a3moss@uwaterloo.ca}, + key = {C++ Concepts}, + title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts}, + organization= {International Standard ISO/IEC TS 19217:2015}, + publisher = {International Standard Organization}, + address = {http://www.iso.org}, + year = 2015 } @@ -914,6 +950,7 @@ title = {{C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Primer}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1991, - edition = {second}, + edition = {2nd}, note = {QA76.73.C15L57}, } @@ -925,6 +962,7 @@ title = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1986, - edition = {first}, + edition = {1st}, series = {Addison-Wesley Series in Computer Science} } @@ -936,6 +974,7 @@ title = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1991, - edition = {second}, + edition = {2nd}, } @@ -945,7 +984,7 @@ author = {Bjarne Stroustrup}, title = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language}, - publisher = {Addison-Wesley}, + publisher = {Addison Wesley Longman}, year = 1997, - edition = {third}, + edition = {3rd}, } @@ -1002,4 +1041,5 @@ title = {Classics in Software Engineering}, publisher = {Yourdon Press}, + address = {New York}, year = 1979, } @@ -1042,5 +1082,6 @@ Moss and J. Craig Schaffert and Robert Scheifler and Alan Snyder}, title = {CLU Reference Manual}, - publisher = {Springer-Verlag}, + publisher = {Springer}, + address = {New York}, year = 1981, volume = 114, @@ -1053,5 +1094,5 @@ key = {Cobol14}, title = {Programming Languages -- {Cobol}}, - edition = {second}, + edition = {2nd}, organization= {International Standard ISO/IEC 1989:2014}, publisher = {International Standard Organization}, @@ -1106,5 +1147,5 @@ title = {Commentary on Standard {ML}}, publisher = {MIT Press}, - address = {Cambridge, Massachusetts, U.S.A.}, + address = {Cambridge}, year = 1991 } @@ -1132,5 +1173,5 @@ year = 1987, pages = {151-170}, - publisher = {Springer-Verlag} + publisher = {Springer} } @@ -1138,7 +1179,8 @@ keywords = {common lisp}, contributer = {pabuhr@plg}, - author = {G. Steele}, + author = {Guy Steele}, title = {COMMON LISP: The Language}, publisher = {Digital Press}, + address = {New York}, year = 1984 } @@ -1183,5 +1225,5 @@ year = 1985, isbn = {0-13-153271-5}, - publisher = {Prentice-Hall, Inc.}, + publisher = {Prentice-Hall}, address = {Upper Saddle River, NJ, USA}, note = {\href{http://www.usingcsp.com/cspbook.pdf}{http://\-www.usingcsp.com/\-cspbook.pdf}}, @@ -1202,7 +1244,7 @@ author = {Alfred V. Aho and Monica S. Lam and Ravi Sethi and Jeffrey D. Ullman}, title = {Compilers: Principles, Techniques, and Tools}, - edition = {second}, + edition = {2nd}, year = {2006}, - publisher = {Addison-Wesley Longman Publishing Co., Inc.}, + publisher = {Addison-Wesley Longman Publishing}, address = {Boston, MA, USA}, } @@ -1212,5 +1254,5 @@ contributer = {pabuhr@plg}, author = {David F. Bacon and Susan L. Graham and Oliver J. Sharp}, - title = {Compiler Transformations for High-Performance Computing}, + title = {Compiler Transformations for High-Performance Com\-puting}, journal = acmcs, volume = 26, @@ -1250,5 +1292,5 @@ month = sep, address = {Waterloo, Ontario, Canada, N2L 3G1}, - note = {{\small\textsf{ftp://\-plg.uwaterloo.ca/\-pub/\-theses/\-MokThesis.ps.gz}}}, + note = {\href{http://plg.uwaterloo.ca/theses/MokThesis.pdf}{http://\-plg.uwaterloo.ca/\-theses/\-MokThesis.pdf}}, } @@ -1328,5 +1370,5 @@ editor = {P. E. Lauer}, pages = {165-198}, - publisher = {Springer-Verlag}, + publisher = {Springer}, address = {Berlin, DE}, year = 1993, @@ -1393,5 +1435,5 @@ month = jul, year = 2015, - note = {\href{http://plg.uwaterloo.ca/~usystem/pub/uSystem/u++-6.1.0.sh}{\textsf{http://plg.uwaterloo.ca/\-$\sim$usystem/\-pub/\-uSystem/\-u++-6.1.0.sh}}}, + note = {\href{http://plg.uwaterloo.ca/~usystem/pub/uSystem/u++-6.1.0.sh}{\textsf{http://\-plg.\-uwaterloo.\-ca/\-$\sim$usystem/\-pub/\-uSystem/\-u++-6.1.0.sh}}}, } @@ -1401,5 +1443,5 @@ author = {Alan Burns and Geoff Davies}, title = {Concurrent Programming}, - publisher = {Addison-Wesley}, + publisher = {Addison Wesley Longman}, year = 1993, } @@ -1424,6 +1466,7 @@ title = {Concurrent Programming in {J}ava: Design Principles and Patterns}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1997, - edition = {first}, + edition = {1st}, } @@ -1435,5 +1478,5 @@ publisher = {Oxford University Press}, year = 1998, - edition = {first}, + edition = {1st}, } @@ -1444,6 +1487,7 @@ title = {Concurrent Programming in {J}ava: Design Principles and Patterns}, publisher = {Addison-Wesley}, + address = {Boston}, year = 2000, - edition = {second}, + edition = {2nd}, } @@ -1453,5 +1497,6 @@ author = {N. H. Gehani and W. D. Roome}, title = {The {Concurrent C} Programming Language}, - publisher = {Silicon Press, NJ}, + publisher = {Silicon Press}, + address = {Summit}, year = 1989, } @@ -1462,5 +1507,6 @@ author = {Gregory R. Andrews}, title = {Concurrent Programming: Principles and Practice}, - publisher = {Benjamin/Cummings Publishing Company, Inc., Redwood City, California}, + publisher = {Benjamin/Cummings Publish\-ing}, + address = {Redwood City}, year = 1991, } @@ -1471,5 +1517,5 @@ author = {Peter A. Buhr and Ashif S. Harji}, title = {Concurrent Urban Legends}, - journal = {Concurrency and Computation: Practice and Experience}, + journal = ccpe, month = aug, year = 2005, @@ -1497,5 +1543,5 @@ publisher = {Cambridge University Press}, year = 1998, - edition = {second}, + edition = {2nd}, } @@ -1514,5 +1560,5 @@ title = {Condition Handling in the Lisp Language Family}, booktitle = {Exception Handling}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 2022, series = {LNCS}, @@ -1527,5 +1573,5 @@ title = {Conformace, Genericity, Inheritance and Enhancement}, pages = {223-233}, - publisher = {Springer-Verlag}, + publisher = {Springer}, year = 1987, volume = 276, @@ -1636,13 +1682,12 @@ @unpublished{Ditchfield:conversions, - contributer = {a3moss@uwaterloo.ca}, - author = {Glen Ditchfield}, - title = {Conversions for {Cforall}}, - note = {\href{http://plg.uwaterloo.ca/~cforall/Conversions/index.html}{http://\-plg.uwaterloo.ca/\-\textasciitilde cforall/\-Conversions/\-index.html}}, - month = {Nov}, - year = {2002}, - urldate = {28 July 2016}, -} - + contributer = {a3moss@uwaterloo.ca}, + author = {Glen Ditchfield}, + title = {Conversions for {Cforall}}, + note = {\href{http://plg.uwaterloo.ca/~cforall/Conversions/index.html}{http://\-plg.uwaterloo.ca/\-\textasciitilde cforall/\-Conversions/\-index.html}}, + month = {Nov}, + year = {2002}, + urldate = {28 July 2016}, +} @techreport{Dijkstra65, @@ -1662,5 +1707,6 @@ author = {Christopher D. Marlin}, title = {Coroutines: A Programming Methodology, a Language Design and an Implementation}, - publisher = {Springer-Verlag}, + publisher = {Springer}, + address = {New York}, year = 1980, volume = 95, @@ -1699,4 +1745,14 @@ publisher = {Benjamin Cummings}, year = 1991, +} + +@article{Moore75, + keywords = {approximation methods, integrated circuits}, + contributer = {pabuhr@plg}, + author = {Gordon E. Moore}, + title = {Progress in Digital Integrated Electronics}, + journal = {Technical Digest, International Electron Devices Meeting, IEEE}, + year = 1975, + pages = {11-13}, } @@ -1840,5 +1896,5 @@ title = {The Definition of Standard {ML}}, publisher = {MIT Press}, - address = {Cambridge, Massachusetts, U.S.A.}, + address = {Cambridge}, year = 1990 } @@ -1870,5 +1926,5 @@ author = {Peter A. Buhr and David Dice and Wim H. Hesselink}, title = {Dekker's Mutual Exclusion Algorithm Made RW-Safe}, - journal = {Concurrency and Computation: Practice and Experience}, + journal = ccpe, volume = 28, number = 1, @@ -1920,4 +1976,5 @@ title = {The Design and Evolution of {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1994 } @@ -1977,5 +2034,6 @@ author = {G. Motet and A. Mapinard and J. C. Geoffroy}, title = {Design of Dependable {A}da Software}, - publisher = {Prentice Hall}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1996, } @@ -2012,4 +2070,5 @@ title = {Design Patterns: Elements of Reusable Object-Oriented Software}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1995, series = {Professional Computing Series}, @@ -2054,5 +2113,5 @@ author = {Ralph E. Johnson and Brian Foote}, title = {Designing Reusable Classes}, - journal = {Journal of Object-Oriented Programming}, + journal = joop, year = 1988, volume = 1, number = 2, pages = {22-35}, @@ -2109,4 +2168,5 @@ title = {A Discipline of Programming}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1976, } @@ -2125,4 +2185,5 @@ title = {Distributed Systems: Principles and Paradigms}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 2002, } @@ -2253,6 +2314,7 @@ title = {Eiffel: The Language}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1992, - series = {Prentice Hall Object-Oriented Series}, + series = {Prentice-Hall Object-Oriented Series}, } @@ -2388,5 +2450,5 @@ month = jun, year = 2015, - note = {\href{http://www.erlang.org/doc/pdf/otp-system-documentation.pdf}{\textsf{http://www.erlang.org/\-doc/\-pdf/\-otp-system-documentation.pdf}}}, + note = {\href{http://www.erlang.org/doc/pdf/otp-system-documentation.pdf}{\textsf{http://www.erlang.org/\-doc/\-pdf/\-otp-system-\-documentation.pdf}}}, } @@ -2467,4 +2529,5 @@ booktitle = {Advances in COMPUTERS}, publisher = {Academic Press}, + address = {London}, volume = 56, year = 2002, @@ -2561,15 +2624,11 @@ title = {Exception Handling in Parallel Computations}, journal = sigplan, + publisher = {ACM}, + address = {New York, NY, USA}, volume = 20, number = 10, month = oct, year = 1985, - issn = {0362-1340}, pages = {95-104}, - url = {http://doi.acm.org/10.1145/382286.382385}, - doi = {http://doi.acm.org/10.1145/382286.382385}, - acmid = {382385}, - publisher = {ACM}, - address = {New York, NY, USA}, } @@ -2680,5 +2739,5 @@ title = {Fault Tolerance and Exception Handling in {BETA}}, booktitle = {Exception Handling}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 2022, series = {Lecture Notes in Computer Science}, @@ -2839,5 +2898,5 @@ title = {A Fully Object-Oriented Exception Handling System: Rationale and Smalltalk Implementation}, booktitle = {Exception Handling}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 2022, series = {Lecture Notes in Computer Science}, @@ -2859,7 +2918,8 @@ series = {The Art of Computer Programming}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1973, volume = 1, - edition = {second}, + edition = {2nd}, } @@ -2912,5 +2972,5 @@ author = {Richard M. Stallman}, organization= {Free Software Foundation}, - address = {Cambridge, MA} + address = {Cambridge} } @@ -2952,5 +3012,4 @@ } - @article{Haskell, keywords = {lazy evaluation, type class}, @@ -2973,5 +3032,5 @@ organization= {Google}, year = 2009, - note = {\href{http://golang.org/ref/spec}{http://golang.org/\-ref/\-spec}}, + note = {\href{http://golang.org/ref/spec}{http://\-golang.org/\-ref/\-spec}}, } @@ -3090,5 +3149,6 @@ author = {Robert E. Strom and David F. Bacon and Arthur P. Goldberg and Andy Lowry and Daniel M. Yellin and Shaula Alexander Yemini}, title = {Hermes: A Language for Distributed Computing}, - publisher = {Prentice Hall}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, series = {Innovative Technology}, year = 1991, @@ -3134,5 +3194,5 @@ author = {Peter A. Buhr and David Dice and Wim H. Hesselink}, title = {High-Performance {$N$}-Thread Software Solutions for Mutual Exclusion}, - journal = {Concurrency and Computation: Practice and Experience}, + journal = ccpe, volume = 27, number = 3, @@ -3148,5 +3208,5 @@ title = {Zum Hilbertschen Aufbau der reellen Zahlen}, publisher = {Springer}, - journal = {Mathematische Annalen}, + journal = mathann, number = 1, volume = 99, @@ -3187,4 +3247,5 @@ title = {The Icon Programming Language}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1983, } @@ -3262,5 +3323,4 @@ issn = {0164-0925}, pages = {1270--1343}, - doi = {http://doi.acm.org/10.1145/1108970.1108975}, publisher = {ACM Press}, address = {New York, NY, USA}, @@ -3277,6 +3337,5 @@ pages = {55-59}, issn = {0163-5719}, - doi = {http://doi.acm.org/10.1145/872736.806932}, - } +} @book{Algol68, @@ -3361,4 +3420,5 @@ title = {Interacting Processes: A Multiparty Approach to Coordinated Distributed Programming}, publisher = {Addison-Wesley}, + address = {Boston}, series = {ACM Press Books}, year = 1996, @@ -3434,4 +3494,5 @@ title = {Introduction to Algorithms}, publisher = {MIT Press/McGraw-Hill}, + address = {Cambridge}, series = {Electrical Engineering and Computer Science Series}, year = 1992, @@ -3444,4 +3505,5 @@ title = {Introduction to Automata Theory, Languages and Computation}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1979, } @@ -3476,6 +3538,7 @@ title = {An Introduction to Operating Systems}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1990, - edition = {second}, + edition = {2nd}, } @@ -3525,5 +3588,5 @@ title = {Issues with Exception Hnadling in Object-Oriented Systems}, booktitle = {ECOOP'97}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 1241, series = {Lecture Notes in Computer Science}, @@ -3553,6 +3616,7 @@ title = {The {Java} Language Specification}, publisher = {Addison-Wesley}, + address = {Reading}, year = 2000, - edition = {second}, + edition = {2nd}, } @@ -3597,5 +3661,5 @@ title = {Konstruktion nichtrekursiver Funktionen}, publisher = {Springer}, - journal = {Mathematische Annalen}, + journal = mathann, number = 111, volume = 1, @@ -3740,4 +3804,5 @@ title = {Lisp 1.5 Primer}, publisher = {Dickenson Publishing}, + address = {Belmont}, year = 1967, } @@ -3937,5 +4002,5 @@ booktitle = {Proceedings of the European Conference on Object Oriented Programming}, organization= {ECOOP'88}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 322, editor = {S. Gjessing and K. Nygaard}, @@ -3979,4 +4044,5 @@ title = {Modern C++ Design: Generic Programming and Design Patterns Applied}, publisher = {Addison-Wesley Professional}, + address = {Boston}, month = feb, year = 2001, @@ -3990,4 +4056,5 @@ title = {Modern Operating Systems}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1992, } @@ -4310,5 +4377,5 @@ title = {Nesting in an Object Oriented Language is NOT for the Birds}, booktitle = {Proceedings of the European Conference on Object Oriented Programming}, - publisher = {Springer-Verlag}, + publisher = {Springer}, volume = 322, editor = {S. Gjessing and K. Nygaard}, @@ -4437,5 +4504,5 @@ editor = {S. Gjessing and K. Nygaard}, organization= {DND, The Norwegian Computer Society}, - publisher = {Springer-Verlag}, + publisher = {Springer}, comment = { Objectives: @@ -4472,4 +4539,5 @@ title = {Object-oriented programming; an evolutionary approach}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1986 } @@ -4481,4 +4549,5 @@ title = {Object-oriented Programming in the {BETA} Programming Language}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1993, } @@ -4512,7 +4581,8 @@ author = {Bertrand Meyer}, title = {Object-oriented Software Construction}, - publisher = {Prentice Hall}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = {1988}, - series = {Prentice Hall International Series in Computer Science}, + series = {Prentice-Hall International Series in Computer Science}, } @@ -4541,6 +4611,7 @@ author = {John Galletly}, title = {{OCCAM} 2: Including {OCCAM} 2.1}, - publisher = {{UCL} (University College London) Press Ltd.}, - edition = {second}, + publisher = {{UCL} (University College London) Press}, + address = {London}, + edition = {2nd}, year = 1996, } @@ -4602,5 +4673,5 @@ month = jul, year = 2013, - note = {\href{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}{\textsf{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}}}, + note = {\href{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}{\textsf{http://\-www.openmp.org/\-mp-documents/\-OpenMP4.0.0.pdf}}}, } @@ -4611,6 +4682,7 @@ title = {Operating Systems}, publisher = {Pearson Prentice-Hall}, + address = {Englewood Cliffs}, year = 2004, - edition = {third}, + edition = {3rd}, } @@ -4621,6 +4693,7 @@ title = {Operating Systems: Internals and Design Principles}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1998, - edition = {third}, + edition = {3rd}, } @@ -4631,6 +4704,7 @@ title = {Operating Systems: Internals and Design Principles}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 2001, - edition = {fourth}, + edition = {4th}, } @@ -4641,6 +4715,7 @@ title = {Operating System Concepts}, publisher = {Addision-Wesley}, + address = {Boston}, year = 1991, - edition = {third}, + edition = {3rd}, } @@ -4651,4 +4726,5 @@ title = {Operating Systems : Design and Implementation}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, series = {Software Series}, year = 1987, @@ -4661,4 +4737,5 @@ title = {Operating System Principles}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1973, } @@ -4670,4 +4747,5 @@ title = {Operating System Principles}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 2003, } @@ -4686,20 +4764,20 @@ @article{Ganzinger80, - contributer = {a3moss@uwaterloo.ca}, - author = {Ganzinger, Harald and Ripken, Knut}, - title = {Operator Identification in {ADA}: Formal Specification, Complexity, and Concrete Implementation}, - journal = {SIGPLAN Notices}, - issue_date = {February 1980}, - volume = {15}, - number = {2}, - month = feb, - year = {1980}, - issn = {0362-1340}, - pages = {30--42}, - numpages = {13}, - url = {http://doi.acm.org/10.1145/947586.947589}, - doi = {10.1145/947586.947589}, - publisher = {ACM}, - address = {New York, NY, USA} + contributer = {a3moss@uwaterloo.ca}, + author = {Ganzinger, Harald and Ripken, Knut}, + title = {Operator Identification in {ADA}: Formal Specification, Complexity, and Concrete Implementation}, + journal = {SIGPLAN Notices}, + issue_date = {February 1980}, + volume = {15}, + number = {2}, + month = feb, + year = {1980}, + issn = {0362-1340}, + pages = {30--42}, + numpages = {13}, + url = {http://doi.acm.org/10.1145/947586.947589}, + doi = {10.1145/947586.947589}, + publisher = {ACM}, + address = {New York, NY, USA} } @@ -4723,5 +4801,5 @@ title = {{OS} and {DOS} {PL/I} Reference Manual}, organization= {International Business Machines}, - edition = {first}, + edition = {1st}, month = sep, year = 1981, @@ -4843,5 +4921,5 @@ booktitle = {Parallel Programming in {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, publisher = {MIT Press}, - address = {Cambridge, MA, USA}, + address = {Cambridge}, series = {Scientific and Engineering Computation Series}, pages = {507-546}, @@ -4922,5 +5000,5 @@ publisher = {Springer--Verlag}, year = 1985, - edition = {third}, + edition = {3rd}, note = {Revised by Andrew B. Mickel and James F. Miner, ISO Pascal Standard} } @@ -4933,5 +5011,5 @@ publisher = {Springer--Verlag}, year = 1975, - edition = {first}, + edition = {1st}, } @@ -4955,5 +5033,5 @@ title = {{P}ascal/{VS} Language Reference Manual}, organization= {International Business Machines}, - edition = {first}, + edition = {1st}, year = 1981, note = {Manual SH20-6168-1}, @@ -5107,4 +5185,5 @@ title = {Principles of Concurrent Programming}, publisher = {Prentice-Hall International}, + address = {Englewood Cliffs}, year = 1982, } @@ -5114,4 +5193,5 @@ title = {Principles of Programming Languages}, publisher = {Prentice-Hall International}, + address = {Englewood Cliffs}, year = 1981, series = {Series in Computer Science} @@ -5185,4 +5265,5 @@ title = {Programming with {POSIX} Threads}, publisher = {Addison-Wesley}, + address = {Boston}, series = {Professional Computing}, year = 1997, @@ -5194,5 +5275,5 @@ author = {J. T. Schwartz and R. B. K. Dewar and E. Dubinsky and E. Schonberg}, title = {Programming with Sets: An Introduction to {SETL}}, - publisher = {Springer-Verlag}, + publisher = {Springer}, year = 1986, } @@ -5235,5 +5316,5 @@ key = {C++14}, title = {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, - edition = {fourth}, + edition = {4th}, organization= {International Standard ISO/IEC 14882:2014 (E)}, publisher = {International Standard Organization}, @@ -5329,7 +5410,8 @@ author = {Niklaus Wirth}, title = {Programming in Modula-2}, - publisher = {Springer-Verlag}, + publisher = {Springer}, + address = {New York}, year = 1988, - edition = {fourth}, + edition = {4th}, series = {Texts and Monographs in Computer Science}, } @@ -5343,5 +5425,5 @@ month = feb, year = 1983, - note = {Published by Springer-Verlag} + note = {Springer, New York}, } @@ -5351,5 +5433,5 @@ title = {The Programming Language {Ada}: Reference Manual}, organization= {United States Department of Defense}, - publisher = {Springer-Verlag}, + publisher = {Springer}, year = 1981 } @@ -5505,22 +5587,22 @@ @article{Grossman06, - keywords = {Cyclone, existential types, polymorphism, type variables}, - contributer = {a3moss@plg}, - author = {Grossman, Dan}, - title = {Quantified Types in an Imperative Language}, - journal = toplas, - issue_date = {May 2006}, - volume = {28}, - number = {3}, - month = may, - year = {2006}, - issn = {0164-0925}, - pages = {429--475}, - numpages = {47}, - url = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/1133651.1133653}, - doi = {10.1145/1133651.1133653}, - acmid = {1133653}, - publisher = {ACM}, - address = {New York, NY, USA}, + keywords = {Cyclone, existential types, polymorphism, type variables}, + contributer = {a3moss@plg}, + author = {Grossman, Dan}, + title = {Quantified Types in an Imperative Language}, + journal = toplas, + issue_date = {May 2006}, + volume = {28}, + number = {3}, + month = may, + year = {2006}, + issn = {0164-0925}, + pages = {429--475}, + numpages = {47}, + url = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/1133651.1133653}, + doi = {10.1145/1133651.1133653}, + acmid = {1133653}, + publisher = {ACM}, + address = {New York, NY, USA}, } @@ -5569,5 +5651,5 @@ title = {{A}da Reference Manual}, edition = {International Standard {ISO}/{IEC} {8652:1995(E)} with {COR.1:2000}}, - organization = {Intermetrics, Inc.}, + organization= {Intermetrics, Inc.}, month = dec, year = 1995, @@ -5579,5 +5661,5 @@ contributer = {pabuhr@plg}, title = {Programming languages -- {Ada}}, - edition = {third}, + edition = {3rd}, organization= {International Standard ISO/IEC 1989:2014}, publisher = {International Standard Organization}, @@ -5604,4 +5686,5 @@ series = {The Real-Time for Java Expert Group, {\small\textsf{http://\-www.rtj.org}}}, publisher = {Addison-Wesley}, + address = {Boston}, year = 2000, } @@ -5755,4 +5838,13 @@ % S +@manual{Scala, + keywords = {Scala programming language}, + contributer = {pabuhr@plg}, + title = {{Scala} Language Specification, Version 2.11}, + organization= {\'{E}cole Polytechnique F\'{e}d\'{e}rale de Lausanne}, + year = 2016, + note = {\href{http://www.scala-lang.org/files/archive/spec/2.11}{http://\-www.scala-lang.org/\-files/\-archive/\-spec/\-2.11}}, +} + @inproceedings{Michael04, keywords = {lock free, dynamic memory allocation}, @@ -5802,5 +5894,5 @@ pages = {51-67}, editor = {G. Kahn and D. B. MacQueen and G. D. Plotkin}, - publisher = {Springer-Verlag}, + publisher = {Springer}, note = {Lecture Notes in Computer Science v. 173}, } @@ -5852,5 +5944,5 @@ month = may, year = 2001, - note = {{\small\textsf{http://www.python.org/peps/pep-0255.html}}}, + note = {\href{http://www.python.org/peps/pep-0255.html}{http://\-www.python.org/\-peps/\-pep-0255.html}}, } @@ -5871,20 +5963,20 @@ @article{Pennello80, - contributer = {a3moss@uwaterloo.ca}, - author = {Pennello, Tom and DeRemer, Frank and Meyers, Richard}, - title = {A Simplified Operator Identification Scheme for {Ada}}, - journal = {SIGPLAN Notices}, - issue_date = {July-August 1980}, - volume = {15}, - number = {7 and 8}, - month = jul, - year = {1980}, - issn = {0362-1340}, - pages = {82--87}, - numpages = {6}, - url = {http://doi.acm.org/10.1145/947680.947688}, - doi = {10.1145/947680.947688}, - publisher = {ACM}, - address = {New York, NY, USA}, + contributer = {a3moss@uwaterloo.ca}, + author = {Pennello, Tom and DeRemer, Frank and Meyers, Richard}, + title = {A Simplified Operator Identification Scheme for {Ada}}, + journal = {SIGPLAN Notices}, + issue_date = {July-August 1980}, + volume = {15}, + number = {7 and 8}, + month = jul, + year = {1980}, + issn = {0362-1340}, + pages = {82--87}, + numpages = {6}, + url = {http://doi.acm.org/10.1145/947680.947688}, + doi = {10.1145/947680.947688}, + publisher = {ACM}, + address = {New York, NY, USA}, } @@ -5927,14 +6019,14 @@ year = {1980}, address = {Lund, Sweden}, - edition = {second}, + edition = {2nd}, } @book{Simula67, - author = "O-J Dahl and B. Myhrhaug and K. Nygaard", - address = "Oslo Norway", + author = {O-J Dahl and B. Myhrhaug and K. Nygaard}, + title = {Simula67 Common Base Language}, month = oct, year = 1970, - publisher = "Norwegian Computing Center", - title = "Simula67 Common Base Language" + publisher = {Norwegian Com\-puting Center}, + address = {Oslo Norway}, } @@ -5945,4 +6037,5 @@ title = {Smalltalk-80: The Language and its Implementation}, publisher = {Addison-Wesley}, + address = {Reading}, year = 1983 } @@ -5966,6 +6059,7 @@ author = {R. E. Griswold and J. F. Poage and I. P. Polonsky}, title = {The SNOBOL4 Programming Language}, - edition = {second}, + edition = {2nd}, publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1971, } @@ -6073,5 +6167,5 @@ author = {R. H. Campbell and A. N. Habermann}, title = {The Specification of Process Synchronization by Path Expressions}, - publisher = {Springer-Verlag}, + publisher = {Springer}, year = 1974, volume = 16, @@ -6117,5 +6211,5 @@ title = {A Standard {ML} Compiler}, booktitle = {Functional Programming Languages and Computer Architecture}, - publisher = {Springer-Verlag}, + publisher = {Springer}, series = {Lecture Notes in Computer Science}, volume = 274, @@ -6172,4 +6266,5 @@ title = {Structured Concurrent Programming with Operating System Applications}, publisher = {Addison-Wesley}, + address = {Boston}, year = 1978, } @@ -6320,5 +6415,6 @@ author = {Gadi Taubenfeld}, title = {Synchronization Algorithms and Concurrent Programming}, - publisher = {Pearson/Prentice Hall}, + publisher = {Pearson/Prentice-Hall}, + address = {Harlow, England}, year = 2006, } @@ -6380,7 +6476,8 @@ author = {Andrew Birrell and Mark R. Brown and Luca Cardelli and Jim Donahue and Lucille Glassman and John Gutag and Jim Harning and Bill Kalsow and Roy Levin and Greg Nelson}, title = {Systems Programming with Modula-3}, - publisher = {Prentice-Hall, Inc.}, + publisher = {Prentice-Hall}, + address = {Englewood Cliffs}, year = 1991, - series = {Prentice Hall Series in Innovative Technology} + series = {Prentice-Hall Series in Innovative Technology} } @@ -6464,5 +6561,5 @@ pages = {408-423}, editor = {B. Robinet}, - publisher = {Springer-Verlag}, + publisher = {Springer}, note = {Lecture Notes in Computer Science, v. 19}, abstract = { @@ -6546,5 +6643,5 @@ publisher = {Holt Software Associates Inc.}, year = 1992, - edition = {third}, + edition = {3rd}, } @@ -6566,4 +6663,5 @@ title = {Tutorial: Programming Language Design}, publisher = {Computer Society Press}, + address = {Los Alamitos}, year = 1980 } @@ -6635,11 +6733,12 @@ % U -@unpublished{uC++book, - keywords = {control structure, concurrency}, +@book{uC++book, + keywords = {control structure, concurrency, uC++}, contributer = {pabuhr@plg}, author = {Peter A. Buhr}, - title = {Understanding Control Flow with Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, - year = 1999, - note = {Textbook in preparation} + title = {Understanding Control Flow: Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}}, + publisher = {Springer}, + address = {Switzerland}, + year = 2016, } @@ -6664,5 +6763,5 @@ booktitle = {Proceedings of the International Workshop on Memory Management}, location = {St. Malo, France}, - publisher = {Springer-Verlag}, + publisher = {Springer}, series = {Lecture Notes in Computer Science}, volume = 637, @@ -6788,4 +6887,5 @@ title = {VAX-11 Architecture Reference Manual}, publisher = {Digital Press}, + address = {Bedford}, month = may, year = 1982, @@ -6796,4 +6896,5 @@ title = {{VAX/VMS} Internals and Data Structures Version 4.4}, publisher = {Digital Press}, + address = {Bedford}, year = 1988, } @@ -6805,5 +6906,6 @@ title = {Verifying a Simplification of Mutual Exclusion by {L}ycklama--{H}adzilacos}, journal = {Acta Informatica}, - publisher = {Springer-Verlag}, + publisher = {Springer}, + address = {New York}, year = {2013}, volume = {50}, @@ -6871,5 +6973,5 @@ month = jun, year = 1985, - note = {\textsf{http://www.hpl.hp.com/\-techreports/\-tandem/\-TR-85.7.pdf}}, + note = {\href{http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf}{http://www.hpl.hp.com/\-techreports/\-tandem/\-TR-85.7.pdf}}, } Index: doc/proposals/concurrency/.gitignore =================================================================== --- doc/proposals/concurrency/.gitignore (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/.gitignore (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,21 @@ +concurrency.aux +concurrency.acn +concurrency.acr +concurrency.alg +concurrency.bbl +concurrency.blg +concurrency.brf +concurrency.dvi +concurrency.glg +concurrency.glo +concurrency.gls +concurrency.idx +concurrency.ind +concurrency.ist +concurrency.log +concurrency.out +concurrency.pdf +concurrency.ps +version.aux +monitor.tex +ext_monitor.tex Index: doc/proposals/concurrency/Makefile =================================================================== --- doc/proposals/concurrency/Makefile (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/Makefile (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,84 @@ +## Define the appropriate configuration variables. + +TeXLIB = .:../../LaTeXmacros:../../LaTeXmacros/listings:../../LaTeXmacros/enumitem:~/bibliographies: +LaTeX = TEXINPUTS=${TeXLIB} && export TEXINPUTS && latex -halt-on-error +BibTeX = BIBINPUTS=${TeXLIB} && export BIBINPUTS && bibtex + +## Define the text source files. + +SOURCES = ${addsuffix .tex, \ +concurrency \ +} + +FIGURES = ${addsuffix .tex, \ + monitor \ + ext_monitor \ +} + +PICTURES = ${addsuffix .pstex, \ +} + +PROGRAMS = ${addsuffix .tex, \ +} + +GRAPHS = ${addsuffix .tex, \ +} + +## Define the documents that need to be made. + +DOCUMENT = concurrency.pdf + +# Directives # + +all : ${DOCUMENT} + +clean : + 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} + +# File Dependencies # + +${DOCUMENT} : ${basename ${DOCUMENT}}.ps + ps2pdf $< + +${basename ${DOCUMENT}}.ps : ${basename ${DOCUMENT}}.dvi + dvips $< -o $@ + +${basename ${DOCUMENT}}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} ${basename ${DOCUMENT}}.tex \ + ../../LaTeXmacros/common.tex ../../LaTeXmacros/indexstyle + # Conditionally create an empty *.ind (index) file for inclusion until makeindex is run. + if [ ! -r ${basename $@}.ind ] ; then touch ${basename $@}.ind ; fi + # Must have *.aux file containing citations for bibtex + if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename $@}.tex ; fi + -${BibTeX} ${basename $@} + # Some citations reference others so run steps again to resolve these citations + ${LaTeX} ${basename $@}.tex + -${BibTeX} ${basename $@} + # Make index from *.aux entries and input index at end of document + makeglossaries ${basename $@} + #${LaTeX} ${basename $@}.tex + # Run again to get index title into table of contents + ${LaTeX} ${basename $@}.tex + -./bump_ver.sh + ${LaTeX} ${basename $@}.tex + + +predefined : + sed -f predefined.sed ${basename ${DOCUMENT}}.tex > ${basename $@}.cf + +## Define the default recipes. + +%.tex : %.fig + fig2dev -L eepic $< > $@ + +%.ps : %.fig + fig2dev -L ps $< > $@ + +%.pstex : %.fig + fig2dev -L pstex $< > $@ + fig2dev -L pstex_t -p $@ $< > $@_t + + +# Local Variables: # +# compile-command: "make" # +# End: # Index: doc/proposals/concurrency/bump_ver.sh =================================================================== --- doc/proposals/concurrency/bump_ver.sh (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/bump_ver.sh (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,6 @@ +#!/bin/bash +if [ ! -f version ]; then + echo "0.0.0" > version +fi + +sed -r 's/([0-9]+\.[0-9]+.)([0-9]+)/echo "\1\$((\2+1))" > version/ge' version > /dev/null Index: doc/proposals/concurrency/concurrency.tex =================================================================== --- doc/proposals/concurrency/concurrency.tex (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/concurrency.tex (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,1027 @@ +% 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-^ +% math escape $...$ (dollar symbol) + +\documentclass[twoside,11pt]{article} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% Latex packages used in the document. +\usepackage[T1]{fontenc} % allow Latin1 (extended ASCII) characters +\usepackage{textcomp} +\usepackage[latin1]{inputenc} +\usepackage{fullpage,times,comment} +\usepackage{epic,eepic} +\usepackage{upquote} % switch curled `'" to straight +\usepackage{calc} +\usepackage{xspace} +\usepackage{graphicx} +\usepackage{tabularx} +\usepackage[acronym]{glossaries} +\usepackage{varioref} % extended references +\usepackage{inconsolata} +\usepackage{listings} % format program code +\usepackage[flushmargin]{footmisc} % support label/reference in footnote +\usepackage{latexsym} % \Box glyph +\usepackage{mathptmx} % better math font with "times" +\usepackage[usenames]{color} +\usepackage[pagewise]{lineno} +\usepackage{fancyhdr} +\renewcommand{\linenumberfont}{\scriptsize\sffamily} +\input{common} % bespoke macros used in the document +\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref} +\usepackage{breakurl} + +\usepackage{tikz} +\def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;} + +\renewcommand{\UrlFont}{\small\sf} + +\setlength{\topmargin}{-0.45in} % move running title into header +\setlength{\headsep}{0.25in} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +% Names used in the document. + +\newcommand{\Version}{1.0.0} +\newcommand{\CS}{C\raisebox{-0.9ex}{\large$^\sharp$}\xspace} + +\newcommand{\Textbf}[2][red]{{\color{#1}{\textbf{#2}}}} +\newcommand{\Emph}[2][red]{{\color{#1}\textbf{\emph{#2}}}} +\newcommand{\R}[1]{\Textbf{#1}} +\newcommand{\B}[1]{{\Textbf[blue]{#1}}} +\newcommand{\G}[1]{{\Textbf[OliveGreen]{#1}}} +\newcommand{\uC}{$\mu$\CC} +\newcommand{\cit}{\textsuperscript{[Citation Needed]}\xspace} +\newcommand{\code}[1]{\lstinline{#1}} +\newcommand{\pseudo}[1]{\lstinline[language=Pseudo]{#1}} + +\input{glossary} + +\newsavebox{\LstBox} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\setcounter{secnumdepth}{3} % number subsubsections +\setcounter{tocdepth}{3} % subsubsections in table of contents +% \linenumbers % comment out to turn off line numbering +\makeindex +\pagestyle{fancy} +\fancyhf{} +\cfoot{\thepage} +\rfoot{v\input{version}} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\begin{document} +% \linenumbers + +\title{Concurrency in \CFA} +\author{Thierry Delisle \\ +Dept. of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada +} + +\maketitle + +% ### # # ####### ###### ####### +% # ## # # # # # # +% # # # # # # # # # +% # # # # # ###### # # +% # # # # # # # # # +% # # ## # # # # # +% ### # # # # # ####### + +\section{Introduction} +This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level construct as the basis of the concurrency in \CFA. +Indeed, for highly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading. + +There 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{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization while parallelism tools are more about performance, cost and resource utilization. + +% ##### ####### # # ##### # # ###### ###### ####### # # ##### # # +% # # # # ## # # # # # # # # # # ## # # # # # +% # # # # # # # # # # # # # # # # # # # # +% # # # # # # # # # ###### ###### ##### # # # # # +% # # # # # # # # # # # # # # # # # # # +% # # # # # ## # # # # # # # # # # ## # # # +% ##### ####### # # ##### ##### # # # # ####### # # ##### # + +\section{Concurrency} +% Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared state, some languages and libraries simply disallow mutable shared-state (Erlang\cite{Erlang}, Haskell\cite{Haskell}, Akka (Scala)\cite{Akka}). In these paradigms, interaction among concurrent objects 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 (i.e. message passing versus routine call). Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective. 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 project proposes Monitors\cite{Hoare74} as the core concurrency construct. +% \\ + +Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared state, some languages and libraries simply disallow mutable shared-state (Erlang\cite{Erlang}, Haskell\cite{Haskell}, Akka (Scala)\cite{Akka}). In these paradigms, interaction among concurrent objects rely on message passing\cite{Thoth,Harmony,V-Kernel} 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 (i.e. message passing versus routine call). Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on non-concurrent constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm\cite{HPP:Study}. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. + +Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. +Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes Monitors as the core concurrency construct. +\\ + +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. + +% # # ####### # # ### ####### ####### ###### ##### +% ## ## # # ## # # # # # # # # # +% # # # # # # # # # # # # # # # # +% # # # # # # # # # # # # ###### ##### +% # # # # # # # # # # # # # # +% # # # # # ## # # # # # # # # +% # # ####### # # ### # ####### # # ##### + +\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} + typedef /*some monitor type*/ monitor; + int f(monitor & m); + + int main() { + monitor m; + f(m); + } +\end{lstlisting} + +% ##### # # # +% # # # # # # +% # # # # # +% # # # # # +% # ####### # # +% # # # # # # +% ##### # # ####### ####### + +\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. +\\ + +Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed through multiple 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 : + +\begin{lstlisting} + mutex struct counter_t { /*...*/ }; + + void ?{}(counter_t & nomutex this); + int ++?(counter_t & mutex this); + void ?{}(Int * this, counter_t & mutex cnt); +\end{lstlisting} +*semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data} +\\ + +This example is of a monitor implementing an atomic counter. Here, the constructor uses the \code{nomutex} keyword to signify that it does not acquire the coroutine mutual exclusion when constructing. This is because object not yet constructed should never be shared and therefore do not require mutual exclusion. The prefix increment operator +uses \code{mutex} to protect the incrementing process from race conditions. Finally, we have a conversion operator from \code{counter_t} to \code{Int}. This conversion may or may not require the \code{mutex} key word depending whether or not reading an \code{Int} is an atomic operation or not. +\\ + +Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. If there were a meaning to routine \code{void foo(counter_t & this)} then one could argue that it should 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. +\\ + +Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters. +\begin{lstlisting} + int f1(monitor & mutex m); + int f2(const monitor & mutex m); + int f3(monitor ** mutex m); + int f4(monitor *[] mutex m); + int f5(graph(monitor*) & mutex m); +\end{lstlisting} + +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). + +% ###### # ####### # +% # # # # # # # +% # # # # # # # +% # # # # # # # +% # # ####### # ####### +% # # # # # # # +% ###### # # # # # + +\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} + mutex struct counter_t { + int value; + }; + + void ?{}(counter_t & nomutex this) { + this.cnt = 0; + } + + int ++?(counter_t & mutex this) { + return ++this->value; + } + + void ?{}(int * this, counter_t & mutex cnt) { + *this = (int)cnt; + } +\end{lstlisting} +\begin{tabular}{ c c } +Thread 1 & Thread 2 \\ +\begin{lstlisting} + void f(counter_t & mutex c) { + for(;;) { + sout | (int)c | endl; + } + } +\end{lstlisting} &\begin{lstlisting} + void g(counter_t & mutex c) { + for(;;) { + ++c; + } + } + +\end{lstlisting} +\end{tabular} +\\ + + +This simple counter offers an example of monitor usage. Notice how the counter is used without any explicit synchronisation and yet supports thread-safe semantics for both reading and writting. \\ + +These simple mutual exclusion semantics also naturally expand to multi-monitor calls. +\begin{lstlisting} + int f(MonitorA & mutex a, MonitorB & mutex b); + + MonitorA a; + MonitorB b; + f(a,b); +\end{lstlisting} + +This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can not lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, this does have significant repercussions relating to scheduling (see \ref{insched} and \ref{extsched}). Furthermore, the ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example : +\begin{lstlisting} + void foo(A & mutex a, B & mutex a) { + //... + } + + void bar(A & mutex a, B & nomutex a) + //... + foo(a, b); + //... + } + + void baz(A & nomutex a, B & mutex a) + //... + foo(a, b); + //... + } +\end{lstlisting} + +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} +Monitors 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 : + +\begin{lstlisting} + mutex struct A { + condition e; + } + + void foo(A & mutex a) { + //... + wait(a.e); + //... + } + + void bar(A & mutex a) { + signal(a.e); + } +\end{lstlisting} + +Here routine \code{foo} waits on the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee. + +\begin{center} +\begin{tabular}{ c @{\hskip 0.65in} c } +Thread 1 & Thread 2 \\ +\begin{lstlisting} +void foo(monitor & mutex a, + monitor & mutex b) { + //... + wait(a.e); + //... +} + +foo(a, b); +\end{lstlisting} &\begin{lstlisting} +void bar(monitor & mutex a, + monitor & mutex b) { + signal(a.e); +} + + + +bar(a, b); +\end{lstlisting} +\end{tabular} +\end{center} + +A 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 (Note that here the use of helper routines is irrelevant, only routines the acquire mutual exclusion have an impact on internal scheduling): + +\begin{center} +\begin{tabular}{|c|c|c|} +Context 1 & Context 2 & Context 3 \\ +\hline +\begin{lstlisting} +condition e; + +void foo(monitor & mutex a, + monitor & mutex b) { + wait(e); +} + + + + + + +foo(a,b); +\end{lstlisting} &\begin{lstlisting} +condition e; + +void bar(monitor & mutex a, + monitor & nomutex b) { + foo(a,b); +} + +void foo(monitor & mutex a, + monitor & mutex b) { + wait(e); +} + +bar(a, b); +\end{lstlisting} &\begin{lstlisting} +condition e; + +void bar(monitor & mutex a, + monitor & nomutex b) { + foo(a,b); +} + +void baz(monitor & nomutex a, + monitor & mutex b) { + wait(e); +} + +bar(a, b); +\end{lstlisting} +\end{tabular} +\end{center} + +This can be interpreted in two different ways : +\begin{flushleft} +\begin{enumerate} + \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{ignoring} nested calls. + \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{considering} nested calls. +\end{enumerate} +\end{flushleft} +While 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, i.e. : + +\begin{center} +\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c} +\begin{lstlisting} +enterMonitor(a); +enterMonitor(b); +// do stuff +leaveMonitor(b); +leaveMonitor(a); +\end{lstlisting} & != &\begin{lstlisting} +enterMonitor(a); +enterMonitor(a, b); +// do stuff +leaveMonitor(a, b); +leaveMonitor(a); +\end{lstlisting} +\end{tabular} +\end{center} + +This is not intuitive because even if both methods 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 acquired monitors, \underline{considering} nesting. 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} actually behaves 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. For this reason this \CFA does not support implicit monitor releasing and uses explicit semantics. +\\ + +The following examples shows three alternatives of explicit wait semantics : +\\ + +\begin{center} +\begin{tabular}{|c|c|c|} +Case 1 & Case 2 & Case 3 \\ +Branding on construction & Explicit release list & Explicit ignore list \\ +\hline +\begin{lstlisting} +void foo(monitor & mutex a, + monitor & mutex b, + condition & c) +{ + // Releases monitors + // branded in ctor + wait(c); +} + +monitor a; +monitor b; +condition1 c1 = {a}; +condition2 c2 = {a, b}; + +//Will release only a +foo(a,b,c1); + +//Will release a and b +foo(a,b,c2); +\end{lstlisting} &\begin{lstlisting} +void foo(monitor & mutex a, + monitor & mutex b, + condition & c) +{ + // Releases monitor a + // Holds monitor b + waitRelease(c, [a]); +} + +monitor a; +monitor b; +condition c; + + + +foo(a,b,c); + + + +\end{lstlisting} &\begin{lstlisting} +void foo(monitor & mutex a, + monitor & mutex b, + condition & c) +{ + // Releases monitor a + // Holds monitor b + waitHold(c, [b]); +} + +monitor a; +monitor b; +condition c; + + + +foo(a,b,c); + + + +\end{lstlisting} +\end{tabular} +\end{center} +(Note : Case 2 and 3 use tuple semantics to pass a variable length list of elements.) +\\ + +All these cases have their pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition is initialized as well as where it is used. On the other hand, it is very clear and explicitly states which monitor is released and which monitor stays 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 releases 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 : +\begin{lstlisting} +void wait(condition & cond) { + waitHold(cond, []); +} +\end{lstlisting} +This 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 : +\begin{lstlisting} +monitor global; + +extern void doStuff(); //uses global + +void foo(monitor & mutex m) { + //... + doStuff(); //warning can release monitor m + //... +} + +foo(global); +\end{lstlisting} + +Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of the 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 the syntax proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition both cases can be supported : +\begin{lstlisting} +struct condition { /*...*/ }; + +// Second argument is a variable length tuple. +void wait(condition & cond, [...] monitorsToRelease); +void signal(condition & cond); + +struct conditionN { /*...*/ }; + +void ?{}(conditionN* this, /*list of N monitors to release*/); +void wait(conditionN & cond); +void signal(conditionN & cond); +\end{lstlisting} + +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 \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor. + +Finally, an additionnal semantic which can be very usefull is the \code{signalBlock} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section. +\\ + +% ####### # # ####### ##### ##### # # ####### ###### +% # # # # # # # # # # # # # +% # # # # # # # # # # # +% ##### # # ##### # ####### ##### # # +% # # # # ### # # # # # # # +% # # # # ### # # # # # # # # # +% ####### # # # ### ##### ##### # # ####### ###### + +\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 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} +\begin{tabular}{|c|c|} +Internal Scheduling & External Scheduling \\ +\hline +\begin{lstlisting} + _Monitor blarg { + condition c; + public: + void f() { signal(c)} + void g() { wait(c); } + private: + } +\end{lstlisting}&\begin{lstlisting} + _Monitor blarg { + + public: + void f(); + void g() { _Accept(f); } + private: + } +\end{lstlisting} +\end{tabular} +\end{center} + +In the case of internal scheduling, the call to \code{wait} only guarantees that \code{g} was the last routine to access the monitor. This intails that the routine \code{f} may have acquired mutual exclusion several times while routine \code{h} was waiting. On the other hand, external scheduling guarantees that while routine \code{h} was waiting, no routine other than \code{g} could acquire the monitor. +\\ + +% # ####### ####### ##### ####### ####### ###### # ##### +% # # # # # # # # # # # # # # # +% # # # # # # # # # # # # # +% # # # # # ##### ##### # # ###### # ##### +% # # # # # # # # # # # # # # +% # # # # # # # # # # # # # # # # +% ####### ####### ####### ##### ####### ####### ###### ##### ##### + +\subsubsection{Loose object definitions} +In \uC, monitor declarations include an exhaustive list of monitor operations. Since \CFA is not object oriented it becomes both more difficult to implement but also less clear for the user : + +\begin{lstlisting} + mutex struct A {}; + + void f(A & mutex a); + 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}[language=Pseudo] + if monitor is free : + enter + elif monitor accepts me : + enter + else : + block +\end{lstlisting} +\end{tabular} +\end{center} + +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 f(A & mutex a) ) +{}; +\end{lstlisting} &\begin{lstlisting} +mutex struct A {} +accept( void f(A & mutex a) ); + +\end{lstlisting} \\ +Alternative 3 & Alternative 4 \\ +\begin{lstlisting} +mutex struct A { + accept( void f(A & mutex a) ) +}; + +\end{lstlisting} &\begin{lstlisting} +mutex struct A { + accept : + void f(A & mutex a) ); +}; +\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. + +% # # # # # ####### ### # # ####### # # +% ## ## # # # # # ## ## # # ## # +% # # # # # # # # # # # # # # # # # # +% # # # # # # # # # # # # # # # # +% # # # # # # # # # # # # # # +% # # # # # # # # # # # # ## +% # # ##### ####### # ### # # ####### # # + +\subsubsection{Multi-monitor scheduling} + +External 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 : +\begin{lstlisting} + accept( void f(mutex struct A & mutex this)) + mutex struct A {}; + + mutex struct B {}; + + void g(A & mutex a, B & mutex b) { + accept(f); //ambiguous, which monitor + } +\end{lstlisting} + +The obvious solution is to specify the correct monitor as follows : + +\begin{lstlisting} + accept( void f(mutex struct A & mutex this)) + mutex struct A {}; + + mutex struct B {}; + + void g(A & mutex a, B & mutex b) { + accept( f, b ); + } +\end{lstlisting} + +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} + accept( void f(mutex struct A & mutex, mutex struct A & mutex)) + mutex struct A {}; + + mutex struct B {}; + + void g(A & mutex a, B & mutex b) { + accept( f, b, a ); + } +\end{lstlisting} + +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. + +% ###### ####### ####### # ### # ##### +% # # # # # # # # # # +% # # # # # # # # # +% # # ##### # # # # # ##### +% # # # # ####### # # # +% # # # # # # # # # # +% ###### ####### # # # ### ####### ##### +% +% ##### # # ####### # # ####### ##### +% # # # # # # # # # # +% # # # # # # # # # +% ##### # # # # ##### # # ##### ##### +% # # # # # # # # # # +% # # # # # # # # # # +% #### # ##### ####### ##### ####### ##### + + +\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 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... + +\newpage +% ###### # ###### # # # ####### # ### ##### # # +% # # # # # # # # # # # # # # # ## ## +% # # # # # # # # # # # # # # # # # # +% ###### # # ###### # # # # ##### # # ##### # # # +% # ####### # # ####### # # # # # # # # +% # # # # # # # # # # # # # # # # +% # # # # # # # ####### ####### ####### ####### ### ##### # # +\section{Parallelism} +Historically, computer performance was about processor speeds and instructions count. However, with heat dissipation being an ever growing challenge, parallelism has become the new source of greatest performance \cite{Sutter05, Sutter05b}. In this decade, it is not longer reasonnable to create high-performance application without caring about parallelism. Indeed, parallelism is an important aspect of performance and more specifically throughput and hardware utilization. The lowest level approach of parallelism is to use \glspl{kthread}. However since these have significant costs and limitations \glspl{kthread} are now mostly used as an implementation tool rather than a user oriented one. There are several alternatives to solve these issues which all have strengths and weaknesses. + +\subsection{User-level threads} +A direct improvement on the \gls{kthread} approach is to use \glspl{uthread}. These threads offer most of the same features that the operating system already provide but can be used on a much larger scale. This is the most powerfull solution as it allows all the features of multi-threading while removing several of the more expensives costs of using kernel threads. The down side is that almost none of the low-level threading complexities are hidden, users still have to think about data races, deadlocks and synchronization issues. This can be somewhat alleviated by a concurrency toolkit with strong garantees but the parallelism toolkit offers very little to reduce complexity in itself. + +Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}. + +\subsection{Jobs and thread pools} +The approach on the opposite end of the spectrum is to base parallelism on \glspl{job}. Indeed, \glspl{job} offer limited flexibility but at the benefit of a simpler user interface. In \gls{job} based systems users express parallelism as units of work and the dependency graph (either explicit or implicit) that tie them together. This means users need not to worry about concurrency but significantly limits the interaction that can occur between different jobs. Indeed, any \gls{job} that blocks also blocks the underlying \gls{kthread}, this effectively mean the CPU utilization, and therefore throughput, will suffer noticeably. +The golden standard of this implementation is Intel's TBB library\cite{TBB}. + +\subsection{Fibers : user-level threads without preemption} +Finally, in the middle of the flexibility versus complexity spectrum lay \glspl{fiber} which offer \glspl{uthread} without the complexity of preemption. This means users don't have to worry about other \glspl{fiber} suddenly executing between two instructions which signficantly reduces complexity. However, any call to IO or other concurrency primitives can lead to context switches. Furthermore, users can also block \glspl{fiber} in the middle of their execution without blocking a full processor core. This means users still have to worry about mutual exclusion, deadlocks and race conditions in their code, raising the complexity significantly. +An example of a language that uses fibers is Go\cite{Go} + +\subsection{Paradigm performance} +While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pin the performance implications of chosing a model at the language level. Indeed, in many situations one of these paradigms will show better performance but it all strongly depends on the usage. Having mostly indepent units of work to execute almost guarantess that the \gls{job} based system will have the best performance. However, add interactions between jobs and the processor utilisation might suffer. User-level threads may allow maximum ressource utilisation but context switches will be more expansive and it is also harder for users to get perfect tunning. As with every example, fibers sit somewhat in the middle of the spectrum. Furthermore, if the units of uninterrupted work are large enough the paradigm choice will be largely amorticised by the actual work done. + +% ##### ####### # ####### ###### ###### +% # # # # # # # # # # +% # # # # # # # # # +% # ##### # # ##### # ###### ###### +% # # ####### # # # # # +% # # # # # # # # # # +% ##### # # # # ###### ###### + +\section{\CFA 's Thread Building Blocks} +As a system level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, it is possible to deconstruct the three paradigms details aboved in order to get simple building blocks. Here is a table showing the core caracteristics of the mentionned paradigms : +\begin{center} +\begin{tabular}[t]{| r | c | c |} +\cline{2-3} +\multicolumn{1}{ c| }{} & Has a stack & Preemptive \\ +\hline +\Glspl{job} & X & X \\ +\hline +\Glspl{fiber} & \checkmark & X \\ +\hline +\Glspl{uthread} & \checkmark & \checkmark \\ +\hline +\end{tabular} +\end{center} + +As shown in section \ref{cfaparadigms} these different blocks being available in \CFA it is trivial to reproduce any of these paradigm. + +% ####### # # ###### ####### # ###### ##### +% # # # # # # # # # # # # +% # # # # # # # # # # # +% # ####### ###### ##### # # # # ##### +% # # # # # # ####### # # # +% # # # # # # # # # # # # +% # # # # # ####### # # ###### ##### + +\subsection{Thread Interface} +The basic building blocks of \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread} and as such offer a flexible and lightweight threading interface (lightweight comparatievely to \glspl{kthread}). A thread can be declared using a struct declaration prefix with the \code{thread} as follows : + +\begin{lstlisting} + thread struct foo {}; +\end{lstlisting} + +Obviously, for this thread implementation to be usefull it must run some user code. Several other threading interfaces use some function pointer representation as the interface of threads (for example : \Csharp \cite{Csharp} and Scala \cite{Scala}). However, we consider that statically tying a \code{main} routine to a thread superseeds this approach. Since the \code{main} routine is definetely a special routine in \CFA, we can reuse the existing syntax for declaring routines with unordinary name, i.e. operator overloading. As such the \code{main} routine of a thread can be defined as such : +\begin{lstlisting} + thread struct foo {}; + + void ?main(thread foo* this) { + /*... Some useful code ...*/ + } +\end{lstlisting} + +With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously : +\begin{lstlisting} + typedef void (*voidFunc)(void); + + thread struct FuncRunner { + voidFunc func; + }; + + //ctor + void ?{}(thread FuncRunner* this, voidFunc inFunc) { + func = inFunc; + } + + //main + void ?main(thread FuncRunner* this) { + this->func(); + } +\end{lstlisting} + +% In this example \code{func} is a function pointer stored in \acrfull{tls}, which is \CFA is both easy to use and completly typesafe. + +Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using an \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is not needed. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs. +\begin{lstlisting} +thread struct FuncRunner; //FuncRunner declared above + +void world() { + sout | "World!" | endl; +} + +void main() { + FuncRunner run = {world}; + //Thread run forks here + + //Print to "Hello " and "World!" will be run concurrently + sout | "Hello " | endl; + + //Implicit join at end of scope +} +\end{lstlisting} +This semantic has several advantages over explicit semantics : typesafety is guaranteed, any thread will always be started and stopped exaclty once and users can't make any progamming errors. Furthermore it naturally follows the memory allocation semantics which means users don't need to learn multiple semantics. + +These semantics also naturally scale to multiple threads meaning basic synchronisation is very simple : +\begin{lstlisting} + thread struct MyThread { + //... + }; + + //ctor + void ?{}(thread MyThread* this) {} + + //main + void ?main(thread MyThread* this) { + //... + } + + void foo() { + MyThread thrds[10]; + //Start 10 threads at the beginning of the scope + + DoStuff(); + + //Wait for the 10 threads to finish + } +\end{lstlisting} + +\newpage +\large{\textbf{WORK IN PROGRESS}} +\subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel} + + +\subsection{Paradigms}\label{cfaparadigms} +Given these building blocks we can then reproduce the all three of the popular paradigms. Indeed, we get \glspl{uthread} as the default paradigm in \CFA. However, disabling \glspl{preemption} on the \gls{cfacluster} means \glspl{cfathread} effectively become \glspl{fiber}. Since several \glspl{cfacluster} with different scheduling policy can coexist in the same application, this allows \glspl{fiber} and \glspl{uthread} to coexist in the runtime of an application. + +% \subsection{High-level options}\label{tasks} +% +% \subsubsection{Thread interface} +% constructors destructors +% initializer lists +% monitors +% +% \subsubsection{Futures} +% +% \subsubsection{Implicit threading} +% Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level. +% +% \begin{center} +% \begin{tabular}[t]{|c|c|c|} +% Sequential & System Parallel & Language Parallel \\ +% \begin{lstlisting} +% void big_sum(int* a, int* b, +% int* out, +% size_t length) +% { +% for(int i = 0; i < length; ++i ) { +% out[i] = a[i] + b[i]; +% } +% } +% +% +% +% +% +% int* a[10000]; +% int* b[10000]; +% int* c[10000]; +% //... fill in a and b ... +% big_sum(a, b, c, 10000); +% \end{lstlisting} &\begin{lstlisting} +% void big_sum(int* a, int* b, +% int* out, +% size_t length) +% { +% range ar(a, a + length); +% range br(b, b + length); +% range or(out, out + length); +% parfor( ai, bi, oi, +% [](int* ai, int* bi, int* oi) { +% oi = ai + bi; +% }); +% } +% +% int* a[10000]; +% int* b[10000]; +% int* c[10000]; +% //... fill in a and b ... +% big_sum(a, b, c, 10000); +% \end{lstlisting}&\begin{lstlisting} +% void big_sum(int* a, int* b, +% int* out, +% size_t length) +% { +% for (ai, bi, oi) in (a, b, out) { +% oi = ai + bi; +% } +% } +% +% +% +% +% +% int* a[10000]; +% int* b[10000]; +% int* c[10000]; +% //... fill in a and b ... +% big_sum(a, b, c, 10000); +% \end{lstlisting} +% \end{tabular} +% \end{center} +% +% \subsection{Machine setup}\label{machine} +% Threads are all good and well but wee still some OS support to fully utilize available hardware. +% +% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads? + +% # # # +% # # # # +% # # # # +% # # # # +% ####### # # +% # # # # +% # # ####### ####### +\section{Putting it all together} + + + + + + + + + + +% ####### # # ####### # # ###### ####### +% # # # # # # # # # +% # # # # # # # # # +% ##### # # # # # ###### ##### +% # # # # # # # # # +% # # # # # # # # # +% # ##### # ##### # # ###### +\section{Future work} +Concurrency and parallelism is still a very active field that strongly benefits from hardware advances. As such certain features that aren't necessarily mature enough in their current state could become relevant in the lifetime of \CFA. +\subsection{Transactions} + +% ####### # # ###### +% # ## # # # +% # # # # # # +% ##### # # # # # +% # # # # # # +% # # ## # # +% ####### # # ###### +\section*{Acknowledgements} + +\clearpage +\printglossary[type=\acronymtype] +\printglossary + +\clearpage +\bibliographystyle{plain} +\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local} + + +\end{document} Index: doc/proposals/concurrency/ext_monitor.fig =================================================================== --- doc/proposals/concurrency/ext_monitor.fig (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/ext_monitor.fig (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,94 @@ +#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 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 4275 3150 Acceptables\001 Index: doc/proposals/concurrency/ext_monitor.fig.bak =================================================================== --- doc/proposals/concurrency/ext_monitor.fig.bak (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/ext_monitor.fig.bak (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -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/glossary.tex =================================================================== --- doc/proposals/concurrency/glossary.tex (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/glossary.tex (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,68 @@ +\makeglossaries +\longnewglossaryentry{uthread} +{name={user-level thread}} +{ +Threads created and managed inside user-space. Each thread has its own stack and its own thread of execution. User-level threads are insisible to the underlying operating system. + +\textit{Synonyms : User threads, Lightweight threads, Green threads, Virtual threads, Tasks.} +} + +\longnewglossaryentry{kthread} +{name={kernel-level thread}} +{ +Threads created and managed inside kernel-space. Each thread has its own stack and its own thread of execution. Kernel-level threads are owned, managed and scheduled by the underlying operating system. + +\textit{Synonyms : OS threads, Hardware threads, Physical threads.} +} + +\longnewglossaryentry{fiber} +{name={fiber}} +{ +Fibers are non-preemptive user-level threads. They share most of the caracteristics of user-level threads except that they cannot be preempted by an other fiber. + +\textit{Synonyms : Tasks.} +} + +\longnewglossaryentry{job} +{name={job}} +{ +Unit of work, often send to a thread pool or worker pool to be executed. Has neither its own stack or its own thread of execution. + +\textit{Synonyms : Tasks.} +} + +\longnewglossaryentry{cfacluster} +{name={cluster}} +{ +TBD... + +\textit{Synonyms : None.} +} + +\longnewglossaryentry{cfacpu} +{name={processor}} +{ +TBD... + +\textit{Synonyms : None.} +} + +\longnewglossaryentry{cfathread} +{name={thread}} +{ +TBD... + +\textit{Synonyms : None.} +} + +\longnewglossaryentry{preemption} +{name={preemption}} +{ +TBD... + +\textit{Synonyms : None.} +} + +\newacronym{tls}{TLS}{Thread Local Storage} +\newacronym{api}{API}{Application Program Interface} +\newacronym{raii}{RAII}{Ressource Acquisition Is Initialization} Index: doc/proposals/concurrency/local.bib =================================================================== --- doc/proposals/concurrency/local.bib (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/local.bib (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,40 @@ +% Predefined journal names: +% acmcs: Computing Surveys acta: Acta Infomatica +% cacm: Communications of the ACM +% ibmjrd: IBM J. Research & Development ibmsj: IBM Systems Journal +% ieeese: IEEE Trans. on Soft. Eng. ieeetc: IEEE Trans. on Computers +% ieeetcad: IEEE Trans. on Computer-Aided Design of Integrated Circuits +% ipl: Information Processing Letters jacm: Journal of the ACM +% jcss: J. Computer & System Sciences scp: Science of Comp. Programming +% sicomp: SIAM J. on Computing tocs: ACM Trans. on Comp. Systems +% tods: ACM Trans. on Database Sys. tog: ACM Trans. on Graphics +% toms: ACM Trans. on Math. Software toois: ACM Trans. on Office Info. Sys. +% toplas: ACM Trans. on Prog. Lang. & Sys. +% tcs: Theoretical Computer Science +@string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"} +@string{ieeese="IEEE Transactions on Software Engineering"} +@string{spe="Software---\-Practice and Experience"} +@string{sigplan="SIGPLAN Notices"} +@string{joop="Journal of Object-Oriented Programming"} +@string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"} +@string{osr="Operating Systems Review"} +@string{pldi="Programming Language Design and Implementation"} + + +@article{HPP:Study, + keywords = {Parallel, Productivity}, + author = {Lorin Hochstein and Jeff Carver and Forrest Shull and Sima Asgari and Victor Basili and Jeffrey K. Hollingsworth and Marvin V. Zelkowitz }, + title = {Parallel Programmer Productivity: A Case Study of Novice Parallel Programmers}, +} + +@article{Chicken, + keywords = {Chicken}, + author = {Doug Zongker}, + title = {Chicken Chicken Chicken: Chicken Chicken}, + year = 2006 +} + +@article{TBB, + keywords = {Intel, TBB}, + title = {Intel Thread Building Blocks}, +} Index: doc/proposals/concurrency/monitor.fig =================================================================== --- doc/proposals/concurrency/monitor.fig (revision f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/monitor.fig (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -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 f51aefb3eeeda889110e1af22563b60669654116) +++ doc/proposals/concurrency/version (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -0,0 +1,1 @@ +0.4.99 Index: doc/user/user.tex =================================================================== --- doc/user/user.tex (revision 40744af8b1bb93262cbdaa65ccf399c6df297cc7) +++ doc/user/user.tex (revision f51aefb3eeeda889110e1af22563b60669654116) @@ -11,6 +11,6 @@ %% Created On : Wed Apr 6 14:53:29 2016 %% Last Modified By : Peter A. Buhr -%% Last Modified On : Sun Aug 14 08:23:06 2016 -%% Update Count : 1323 +%% Last Modified On : Tue Oct 25 23:03:59 2016 +%% Update Count : 1357 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -33,4 +33,5 @@ \usepackage{textcomp} \usepackage[latin1]{inputenc} + \usepackage{fullpage,times,comment} \usepackage{epic,eepic} @@ -325,6 +326,6 @@ \begin{description} \item -\Indexc{__CFA__}\index{preprocessor variables!__CFA__@{©__CFA__©}} -is always available during preprocessing and its value is the current major \Index{version number} of \CFA.\footnote{ +\Indexc{__CFA_MAJOR__}\index{preprocessor variables!__CFA__@{©__CFA__©}} +is available during preprocessing and its value is the major \Index{version number} of \CFA.\footnote{ The C preprocessor allows only integer values in a preprocessor variable so a value like ``\Version'' is not allowed. Hence, the need to have three variables for the major, minor and patch version number.} @@ -332,13 +333,14 @@ \item \Indexc{__CFA_MINOR__}\index{preprocessor variables!__CFA_MINOR__@{©__CFA_MINOR__©}} -is always available during preprocessing and its value is the current minor \Index{version number} of \CFA. +is available during preprocessing and its value is the minor \Index{version number} of \CFA. \item \Indexc{__CFA_PATCH__}\index{preprocessor variables!__CFA_PATCH__@©__CFA_PATCH__©} -is always available during preprocessing and its value is the current patch \Index{version number} of \CFA. - -\item +is available during preprocessing and its value is the patch \Index{level number} of \CFA. + +\item +\Indexc{__CFA__}\index{preprocessor variables!__CFA__@©__CFA__©} and \Indexc{__CFORALL__}\index{preprocessor variables!__CFORALL__@©__CFORALL__©} -is always available during preprocessing and has no value. +are always available during preprocessing and have no value. \end{description} These preprocessor variables allow conditional compilation of programs that must work differently in these situations. @@ -1853,11 +1855,7 @@ case 1: case 2: case 3: ... \end{lstlisting} -still work. +still works. Nevertheless, reversing the default action would have a non-trivial effect on case actions that compound, such as the above example of processing shell arguments. -<<<<<<< HEAD -Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthru©, \eg: -======= Therefore, to preserve backwards compatibility, it is necessary to introduce a new kind of ©switch© statement, called ©choose©, with no implicit fall-through semantics and an explicit fall-through if the last statement of a case-clause ends with the new keyword ©fallthrough©/©fallthru©, e.g.: ->>>>>>> 080615890f586cb9954c252b55cab47f52c25758 \begin{lstlisting} ®choose® ( i ) {