Changeset b726084


Ignore:
Timestamp:
Nov 9, 2016, 2:51:42 PM (7 years ago)
Author:
Rob Schluntz <rschlunt@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc
Children:
30b65d8, d073e3c
Parents:
141b786 (diff), 84118d8 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' into tuples

Conflicts:

src/ControlStruct/LabelTypeChecker.cc
src/InitTweak/FixInit.cc
src/ResolvExpr/Resolver.cc
src/Tuples/TupleAssignment.cc
src/Tuples/TupleAssignment.h

Files:
3 added
1 deleted
31 edited

Legend:

Unmodified
Added
Removed

  • .gitignore

    r141b786 rb726084  
    1212libcfa/Makefile
    1313src/Makefile
     14version
    1415
    1516# genereted by premake

  • Makefile.in

    r141b786 rb726084  
    132132CFA_PREFIX = @CFA_PREFIX@
    133133CFLAGS = @CFLAGS@
    134 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    135134CPP = @CPP@
    136135CPPFLAGS = @CPPFLAGS@

  • configure

    r141b786 rb726084  
    11#! /bin/sh
    22# Guess values for system-dependent variables and create Makefiles.
    3 # Generated by GNU Autoconf 2.68 for cfa-cc 1.0.0.
     3# Generated by GNU Autoconf 2.68 for cfa-cc 1.0.0.0.
    44#
    55# Report bugs to <cforall@plg.uwaterloo.ca>.
    … …  
    561561PACKAGE_NAME='cfa-cc'
    562562PACKAGE_TARNAME='cfa-cc'
    563 PACKAGE_VERSION='1.0.0'
    564 PACKAGE_STRING='cfa-cc 1.0.0'
     563PACKAGE_VERSION='1.0.0.0'
     564PACKAGE_STRING='cfa-cc 1.0.0.0'
    565565PACKAGE_BUGREPORT='cforall@plg.uwaterloo.ca'
    566566PACKAGE_URL=''
    … …  
    646646CFA_BACKEND_CC
    647647BACKEND_CC
    648 CONFIG_STATUS_DEPENDENCIES
    649648MAINT
    650649MAINTAINER_MODE_FALSE
    … …  
    12791278  # This message is too long to be a string in the A/UX 3.1 sh.
    12801279  cat <<_ACEOF
    1281 \`configure' configures cfa-cc 1.0.0 to adapt to many kinds of systems.
     1280\`configure' configures cfa-cc 1.0.0.0 to adapt to many kinds of systems.
    12821281
    12831282Usage: $0 [OPTION]... [VAR=VALUE]...
    … …  
    13451344if test -n "$ac_init_help"; then
    13461345  case $ac_init_help in
    1347      short | recursive ) echo "Configuration of cfa-cc 1.0.0:";;
     1346     short | recursive ) echo "Configuration of cfa-cc 1.0.0.0:";;
    13481347   esac
    13491348  cat <<\_ACEOF
    … …  
    14491448if $ac_init_version; then
    14501449  cat <<\_ACEOF
    1451 cfa-cc configure 1.0.0
     1450cfa-cc configure 1.0.0.0
    14521451generated by GNU Autoconf 2.68
    14531452
    … …  
    20372036running configure, to aid debugging if configure makes a mistake.
    20382037
    2039 It was created by cfa-cc $as_me 1.0.0, which was
     2038It was created by cfa-cc $as_me 1.0.0.0, which was
    20402039generated by GNU Autoconf 2.68.  Invocation command line was
    20412040
    … …  
    29012900# Define the identity of the package.
    29022901 PACKAGE='cfa-cc'
    2903  VERSION='1.0.0'
     2902 VERSION='1.0.0.0'
    29042903
    29052904
    … …  
    29652964                        # may require auto* software to be installed
    29662965
    2967 ver_major=`cat version | sed -r 's/([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)/\1/'`
    2968 ver_minor=`cat version | sed -r 's/([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)/\2/'`
    2969 ver_patch=`cat version | sed -r 's/([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)/\3/'`
    2970 ver_build=`cat version | sed -r 's/([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)/\4/'`
    2971 ver_short="\"${ver_major}\""
    2972 ver__long="\"${ver_major}.${ver_minor}\""
    2973 ver__norm="\"${ver_major}.${ver_minor}.${ver_patch}\""
    2974 ver__full="\"${ver_major}.${ver_minor}.${ver_patch}.${ver_build}\""
    2975 
    2976 CONFIG_STATUS_DEPENDENCIES='$(top_srcdir)/version'
    2977 
     2966rm -f version
     2967echo ${PACKAGE_VERSION} > version               # file containing version number for other tools
     2968chmod ugo-w version
     2969ver_major=`cut -d '.' -f1 version`              # subdivide version number into components at periods
     2970ver_minor=`cut -d '.' -f2 version`
     2971ver_patch=`cut -d '.' -f3 version`
     2972ver_build=`cut -d '.' -f4 version`
     2973
     2974# AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version'])
    29782975
    29792976cat >>confdefs.h <<_ACEOF
    … …  
    29982995
    29992996cat >>confdefs.h <<_ACEOF
    3000 #define CFA_VERSION_SHORT ${ver_short}
     2997#define CFA_VERSION_SHORT "${ver_major}"
    30012998_ACEOF
    30022999
    30033000
    30043001cat >>confdefs.h <<_ACEOF
    3005 #define CFA_VERSION ${ver__long}
     3002#define CFA_VERSION "${ver_major}.${ver_minor}"
    30063003_ACEOF
    30073004
    30083005
    30093006cat >>confdefs.h <<_ACEOF
    3010 #define CFA_VERSION_LONG ${ver__norm}
     3007#define CFA_VERSION_LONG "${ver_major}.${ver_minor}.${ver_patch}"
    30113008_ACEOF
    30123009
    30133010
    30143011cat >>confdefs.h <<_ACEOF
    3015 #define CFA_VERSION_FULL ${ver__full}
     3012#define CFA_VERSION_FULL "${ver_major}.${ver_minor}.${ver_patch}.${ver_build}"
    30163013_ACEOF
    30173014
    … …  
    64046401# values after options handling.
    64056402ac_log="
    6406 This file was extended by cfa-cc $as_me 1.0.0, which was
     6403This file was extended by cfa-cc $as_me 1.0.0.0, which was
    64076404generated by GNU Autoconf 2.68.  Invocation command line was
    64086405
    … …  
    64706467ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`"
    64716468ac_cs_version="\\
    6472 cfa-cc config.status 1.0.0
     6469cfa-cc config.status 1.0.0.0
    64736470configured by $0, generated by GNU Autoconf 2.68,
    64746471  with options \\"\$ac_cs_config\\"

  • configure.ac

    r141b786 rb726084  
    33
    44AC_PREREQ([2.68])
    5 AC_INIT([cfa-cc],[1.0.0],[cforall@plg.uwaterloo.ca])
     5AC_INIT([cfa-cc],[1.0.0.0],[cforall@plg.uwaterloo.ca])
    66AC_CONFIG_AUX_DIR([automake])
    77#AC_CONFIG_SRCDIR([src/main.cc])
    … …  
    1818AM_MAINTAINER_MODE(enable)                      # may require auto* software to be installed
    1919
    20 ver_major=`cat version | sed -r 's/([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)/\1/'`
    21 ver_minor=`cat version | sed -r 's/([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)/\2/'`
    22 ver_patch=`cat version | sed -r 's/([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)/\3/'`
    23 ver_build=`cat version | sed -r 's/([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)\.([[0-9]]+)/\4/'`
    24 ver_short="\"${ver_major}\""
    25 ver__long="\"${ver_major}.${ver_minor}\""
    26 ver__norm="\"${ver_major}.${ver_minor}.${ver_patch}\""
    27 ver__full="\"${ver_major}.${ver_minor}.${ver_patch}.${ver_build}\""
     20rm -f version
     21echo ${PACKAGE_VERSION} > version               # file containing version number for other tools
     22chmod ugo-w version
     23ver_major=`cut -d '.' -f1 version`              # subdivide version number into components at periods
     24ver_minor=`cut -d '.' -f2 version`
     25ver_patch=`cut -d '.' -f3 version`
     26ver_build=`cut -d '.' -f4 version`
    2827
    29 AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version'])
     28# AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version'])
    3029AC_DEFINE_UNQUOTED(CFA_VERSION_MAJOR, ${ver_major}, [Major version number.])
    3130AC_DEFINE_UNQUOTED(CFA_VERSION_MINOR, ${ver_minor}, [Minor version number.])
    3231AC_DEFINE_UNQUOTED(CFA_VERSION_PATCH, ${ver_patch}, [Patch version number.])
    3332AC_DEFINE_UNQUOTED(CFA_VERSION_BUILD, ${ver_build}, [Build version number.])
    34 AC_DEFINE_UNQUOTED(CFA_VERSION_SHORT, ${ver_short}, [Major])
    35 AC_DEFINE_UNQUOTED(CFA_VERSION, ${ver__long}, [Major.Minor])
    36 AC_DEFINE_UNQUOTED(CFA_VERSION_LONG, ${ver__norm}, [Major.Minor.Patch])
    37 AC_DEFINE_UNQUOTED(CFA_VERSION_FULL, ${ver__full}, [Major.Minor.Patch.Build])
     33AC_DEFINE_UNQUOTED(CFA_VERSION_SHORT, ["${ver_major}"], [Major])
     34AC_DEFINE_UNQUOTED(CFA_VERSION, ["${ver_major}.${ver_minor}"], [Major.Minor])
     35AC_DEFINE_UNQUOTED(CFA_VERSION_LONG, ["${ver_major}.${ver_minor}.${ver_patch}"], [Major.Minor.Patch])
     36AC_DEFINE_UNQUOTED(CFA_VERSION_FULL, ["${ver_major}.${ver_minor}.${ver_patch}.${ver_build}"], [Major.Minor.Patch.Build])
    3837
    3938# Installation paths

  • doc/bibliography/cfa.bib

    r141b786 rb726084  
    2121%  tcs: Theoretical Computer Science
    2222@string{ieeepds="IEEE Transactions on Parallel and Distributed Systems"}
     23% @string{ieeepds="IEEE Trans. Parallel Distrib. Syst."}
    2324@string{ieeese="IEEE Transactions on Software Engineering"}
     25% @string{ieeese="IEEE Trans. Softw. Eng."}
    2426@string{spe="Software---\-Practice and Experience"}
     27% @string{spe="Softw. Pract. Exp."}
     28@string{ccpe="Concurrency and Computation: Practice and Experience"}
     29% @string{ccpe="Concurrency Comput. Pract. Exp."}
    2530@string{sigplan="SIGPLAN Notices"}
     31% @string{sigplan="SIGPLAN Not."}
    2632@string{joop="Journal of Object-Oriented Programming"}
     33% @string{joop="J. of Object-Oriented Program."}
    2734@string{popl="Conference Record of the ACM Symposium on Principles of Programming Languages"}
    2835@string{osr="Operating Systems Review"}
    2936@string{pldi="Programming Language Design and Implementation"}
     37@string{mathann="Mathematische Annalen"}
     38% @string{mathann="Math. Ann."}
    3039
    3140% A
    … …  
    3948    booktitle   = {Parallel Programming in {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    4049    publisher   = {MIT Press},
     50    address     = {New York},
    4151    series      = {Scientific and Engineering Computation Series},
    4252    year        = 1996,
    … …  
    120130    year        = 1996,
    121131    pages       = {483-499},
    122     publisher   = {Addison-Wesley Longman Publishing Co., Inc.},
    123     address     = {Boston, MA, USA},
     132    publisher   = {Addison-Wesley Longman Publishing},
     133    address     = {Boston},
    124134}
    125135
    … …  
    161171    author      = {Gul A. Agha},
    162172    title       = {Actors: A Model of Concurrent Computation in Distributed Systems},
    163     publisher   = {MIT Press, Cambridge, Mass.},
     173    publisher   = {MIT Press, Cambridge},
    164174    year        = 1986
    165175}
    … …  
    311321    publisher   = {Microsoft Press},
    312322    year        = 1997,
    313     edition     = {third},
     323    edition     = {3rd},
    314324}
    315325
    … …  
    325335    year        = 1977,
    326336    pages       = {604-605},
     337}
     338
     339@manual{Akka,
     340    keywords    = {Akka actor model},
     341    contributer = {pabuhr@plg},
     342    title       = {{A}kka {S}cala Documentation, Release 2.4.11},
     343    organization= {Lightbend Inc.},
     344    month       = sep,
     345    year        = 2016,
     346    note        = {\href{http://doc.akka.io/docs/akka/2.4/AkkaScala.pdf}{http://\-doc.akka.io/\-docs/\-akka/\-2.4/\-AkkaScala.pdf}},
    327347}
    328348
    … …  
    378398    author      = {M. Raynal},
    379399    title       = {Algorithms for Mutual Exclusion},
    380     publisher   = {The MIT Press},
    381     address     = {Cambridge, Massachusetts},
     400    publisher   = {MIT Press},
     401    address     = {Cambridge},
    382402    series      = {Scientific Computation Series},
    383403    year        = 1986,
    … …  
    394414    pages       = {329-342},
    395415    publisher   = {Springer},
     416    address     = {New York},
    396417    year        = 2005,
    397418    volume      = 3669,
    … …  
    404425    editor      = {Richard L. Sites},
    405426    title       = {Alpha Architecture Reference Manual},
    406     publisher   = {Digital Press, One Burlington Woods Drive, Burlington, MA, U. S. A., 01803},
     427    publisher   = {Digital Press, Burlington},
    407428    year        = 1992,
    408429}
    … …  
    413434    editor      = {Mary Shaw},
    414435    title       = {{ALPHARD}: Form and Content},
    415     publisher   = {Springer-Verlag},
     436    publisher   = {Springer},
     437    address     = {New York},
    416438    year        = 1981,
    417439    comment     = {Collection of papers about Alphard.}
    … …  
    470492    editor      = {Gul Agha and Peter Wegner and Akinori Yonezawa},
    471493    publisher   = {MIT Press},
     494    address     = {New York},
    472495    year        = 1993,
    473496    pages       = {107-150},
    … …  
    495518    location    = {Toulouse, France},
    496519    doi         = {http://doi.acm.org/10.1145/318773.319251},
    497     publisher   = {Springer-Verlag},
     520    publisher   = {Springer},
    498521    address     = {London, UK},
    499522}
    … …  
    504527    title       = {The Annotated {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Reference Manual},
    505528    publisher   = {Addison-Wesley},
     529    address     = {Boston},
    506530    year        = 1990,
    507     edition     = {first},
     531    edition     = {1st},
    508532}
    509533
    … …  
    567591    year        = 2008,
    568592    isbn        = {0123705916, 9780123705914},
    569     publisher   = {Morgan Kaufmann Publishers Inc.},
    570     address     = {San Francisco, CA, USA},
     593    publisher   = {Morgan Kaufmann Publishers},
     594    address     = {San Francisco},
    571595}
    572596
    … …  
    747771}
    748772
     773@misc{BoostCoroutines15,
     774    keywords    = {Boost Coroutine Library},
     775    contributer = {pabuhr@plg},
     776    author      = {Oliver Kowalke},
     777    title       = {Boost Coroutine Library},
     778    year        = 2015,
     779    note        = {\href{http://www.boost.org/doc/libs/1_61_0/libs/coroutine/doc/html/index.html}
     780                  {{http://www.boost.org/\-doc/\-libs/1\_61\_0/\-libs/\-coroutine/\-doc/\-html/\-index.html}} [Accessed September 2016]},
     781}
     782
    749783@mastersthesis{Krischer02,
    750784    author      = {Roy Krischer },
    … …  
    779813    editor      = {C. Dony and J. L. Knudsen and A. Romanovsky and A. Tripathi},
    780814    booktitle   = {Advanced Topics in Exception Handling Techniques},
    781     publisher   = {Springer-Verlag},
     815    publisher   = {Springer},
    782816    series      = {Lecture Notes in Computer Science},
    783817    volume      = 4119,
    … …  
    793827    author      = {Brian W. Kernighan and Dennis M. Ritchie},
    794828    title       = {The {C} Programming Language},
    795     publisher   = {Prentice Hall},
     829    publisher   = {Prentice-Hall},
     830    address     = {Englewood Cliffs},
    796831    year        = 1988,
    797     edition     = {second},
    798     series      = {Prentice Hall Software Series},
     832    edition     = {2nd},
     833    series      = {Prentice-Hall Software Series},
    799834    comment     = {
    800835         based on draft-proposed ANSI C
    … …  
    807842    author      = {Brian W. Kernighan and Dennis M. Ritchie},
    808843    title       = {The {C} Programming Language},
    809     publisher   = {Prentice Hall},
     844    publisher   = {Prentice-Hall},
     845    address     = {Englewood Cliffs},
    810846    year        = 1978,
    811     edition     = {first},
     847    edition     = {1st},
    812848}
    813849
    … …  
    835871
    836872@manual{C++Concepts,
    837         keywords = {ISO/IEC TS 19217:2015},
    838         contributer = {a3moss@uwaterloo.ca},
    839         key = {C++ Concepts},
    840         title = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
    841         organization = {International Standard ISO/IEC TS 19217:2015},
    842         publisher = {International Standard Organization},
    843         address = {http://www.iso.org},
    844         year = 2015
     873    keywords    = {ISO/IEC TS 19217:2015},
     874    contributer = {a3moss@uwaterloo.ca},
     875    key         = {C++ Concepts},
     876    title       = {Information technology -- Programming languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Extensions for concepts},
     877    organization= {International Standard ISO/IEC TS 19217:2015},
     878    publisher   = {International Standard Organization},
     879    address     = {http://www.iso.org},
     880    year        = 2015
    845881}
    846882
    … …  
    914950    title       = {{C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Primer},
    915951    publisher   = {Addison-Wesley},
     952    address     = {Boston},
    916953    year        = 1991,
    917     edition     = {second},
     954    edition     = {2nd},
    918955    note        = {QA76.73.C15L57},
    919956}
    … …  
    925962    title       = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language},
    926963    publisher   = {Addison-Wesley},
     964    address     = {Boston},
    927965    year        = 1986,
    928     edition     = {first},
     966    edition     = {1st},
    929967    series      = {Addison-Wesley Series in Computer Science}
    930968}
    … …  
    936974    title       = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language},
    937975    publisher   = {Addison-Wesley},
     976    address     = {Boston},
    938977    year        = 1991,
    939     edition     = {second},
     978    edition     = {2nd},
    940979}
    941980
    … …  
    945984    author      = {Bjarne Stroustrup},
    946985    title       = {The {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}} Programming Language},
    947     publisher   = {Addison-Wesley},
     986    publisher   = {Addison Wesley Longman},
    948987    year        = 1997,
    949     edition     = {third},
     988    edition     = {3rd},
    950989}
    951990
    … …  
    10021041    title       = {Classics in Software Engineering},
    10031042    publisher   = {Yourdon Press},
     1043    address     = {New York},
    10041044    year        = 1979,
    10051045}
    … …  
    10421082                Moss and J. Craig Schaffert and Robert Scheifler and Alan Snyder},
    10431083    title       = {CLU Reference Manual},
    1044     publisher   = {Springer-Verlag},
     1084    publisher   = {Springer},
     1085    address     = {New York},
    10451086    year        = 1981,
    10461087    volume      = 114,
    … …  
    10531094    key         = {Cobol14},
    10541095    title       = {Programming Languages -- {Cobol}},
    1055     edition     = {second},
     1096    edition     = {2nd},
    10561097    organization= {International Standard ISO/IEC 1989:2014},
    10571098    publisher   = {International Standard Organization},
    … …  
    11061147    title       = {Commentary on Standard {ML}},
    11071148    publisher   = {MIT Press},
    1108     address     = {Cambridge, Massachusetts, U.S.A.},
     1149    address     = {Cambridge},
    11091150    year        = 1991
    11101151}
    … …  
    11321173    year        = 1987,
    11331174    pages       = {151-170},
    1134     publisher   = {Springer-Verlag}
     1175    publisher   = {Springer}
    11351176}
    11361177
    … …  
    11381179    keywords    = {common lisp},
    11391180    contributer = {pabuhr@plg},
    1140     author      = {G. Steele},
     1181    author      = {Guy Steele},
    11411182    title       = {COMMON LISP: The Language},
    11421183    publisher   = {Digital Press},
     1184    address     = {New York},
    11431185    year        = 1984
    11441186}
    … …  
    11831225    year        = 1985,
    11841226    isbn        = {0-13-153271-5},
    1185     publisher   = {Prentice-Hall, Inc.},
     1227    publisher   = {Prentice-Hall},
    11861228    address     = {Upper Saddle River, NJ, USA},
    11871229    note        = {\href{http://www.usingcsp.com/cspbook.pdf}{http://\-www.usingcsp.com/\-cspbook.pdf}},
    … …  
    12021244    author      = {Alfred V. Aho and Monica S. Lam and Ravi Sethi and Jeffrey D. Ullman},
    12031245    title       = {Compilers: Principles, Techniques, and Tools},
    1204     edition     = {second},
     1246    edition     = {2nd},
    12051247    year        = {2006},
    1206     publisher   = {Addison-Wesley Longman Publishing Co., Inc.},
     1248    publisher   = {Addison-Wesley Longman Publishing},
    12071249    address     = {Boston, MA, USA},
    12081250}
    … …  
    12121254    contributer = {pabuhr@plg},
    12131255    author      = {David F. Bacon and Susan L. Graham and Oliver J. Sharp},
    1214     title       = {Compiler Transformations for High-Performance Computing},
     1256    title       = {Compiler Transformations for High-Performance Com\-puting},
    12151257    journal     = acmcs,
    12161258    volume      = 26,
    … …  
    12501292    month       = sep,
    12511293    address     = {Waterloo, Ontario, Canada, N2L 3G1},
    1252     note        = {{\small\textsf{ftp://\-plg.uwaterloo.ca/\-pub/\-theses/\-MokThesis.ps.gz}}},
     1294    note        = {\href{http://plg.uwaterloo.ca/theses/MokThesis.pdf}{http://\-plg.uwaterloo.ca/\-theses/\-MokThesis.pdf}},
    12531295}
    12541296
    … …  
    13281370    editor      = {P. E. Lauer},
    13291371    pages       = {165-198},
    1330     publisher   = {Springer-Verlag},
     1372    publisher   = {Springer},
    13311373    address     = {Berlin, DE},
    13321374    year        = 1993,
    … …  
    13931435    month       = jul,
    13941436    year        = 2015,
    1395     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}}},
     1437    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}}},
    13961438}
    13971439
    … …  
    14011443    author      = {Alan Burns and Geoff Davies},
    14021444    title       = {Concurrent Programming},
    1403     publisher   = {Addison-Wesley},
     1445    publisher   = {Addison Wesley Longman},
    14041446    year        = 1993,
    14051447}
    … …  
    14241466    title       = {Concurrent Programming in {J}ava: Design Principles and Patterns},
    14251467    publisher   = {Addison-Wesley},
     1468    address     = {Boston},
    14261469    year        = 1997,
    1427     edition     = {first},
     1470    edition     = {1st},
    14281471}
    14291472
    … …  
    14351478    publisher   = {Oxford University Press},
    14361479    year        = 1998,
    1437     edition     = {first},
     1480    edition     = {1st},
    14381481}
    14391482
    … …  
    14441487    title       = {Concurrent Programming in {J}ava: Design Principles and Patterns},
    14451488    publisher   = {Addison-Wesley},
     1489    address     = {Boston},
    14461490    year        = 2000,
    1447     edition     = {second},
     1491    edition     = {2nd},
    14481492}
    14491493
    … …  
    14531497    author      = {N. H. Gehani and W. D. Roome},
    14541498    title       = {The {Concurrent C} Programming Language},
    1455     publisher   = {Silicon Press, NJ},
     1499    publisher   = {Silicon Press},
     1500    address     = {Summit},
    14561501    year        = 1989,
    14571502}
    … …  
    14621507    author      = {Gregory R. Andrews},
    14631508    title       = {Concurrent Programming: Principles and Practice},
    1464     publisher   = {Benjamin/Cummings Publishing Company, Inc., Redwood City, California},
     1509    publisher   = {Benjamin/Cummings Publish\-ing},
     1510    address     = {Redwood City},
    14651511    year        = 1991,
    14661512}
    … …  
    14711517    author      = {Peter A. Buhr and Ashif S. Harji},
    14721518    title       = {Concurrent Urban Legends},
    1473     journal     = {Concurrency and Computation: Practice and Experience},
     1519    journal     = ccpe,
    14741520    month       = aug,
    14751521    year        = 2005,
    … …  
    14971543    publisher   = {Cambridge University Press},
    14981544    year        = 1998,
    1499     edition     = {second},
     1545    edition     = {2nd},
    15001546}
    15011547
    … …  
    15141560    title       = {Condition Handling in the Lisp Language Family},
    15151561    booktitle   = {Exception Handling},
    1516     publisher   = {Springer-Verlag},
     1562    publisher   = {Springer},
    15171563    volume      = 2022,
    15181564    series      = {LNCS},
    … …  
    15271573    title       = {Conformace, Genericity, Inheritance and Enhancement},
    15281574    pages       = {223-233},
    1529     publisher   = {Springer-Verlag},
     1575    publisher   = {Springer},
    15301576    year        = 1987,
    15311577    volume      = 276,
    … …  
    16361682
    16371683@unpublished{Ditchfield:conversions,
    1638         contributer = {a3moss@uwaterloo.ca},
    1639         author = {Glen Ditchfield},
    1640         title = {Conversions for {Cforall}},
    1641         note = {\href{http://plg.uwaterloo.ca/~cforall/Conversions/index.html}{http://\-plg.uwaterloo.ca/\-\textasciitilde cforall/\-Conversions/\-index.html}},
    1642         month = {Nov},
    1643         year = {2002},
    1644         urldate = {28 July 2016},
    1645 }
    1646 
     1684    contributer = {a3moss@uwaterloo.ca},
     1685    author      = {Glen Ditchfield},
     1686    title       = {Conversions for {Cforall}},
     1687    note        = {\href{http://plg.uwaterloo.ca/~cforall/Conversions/index.html}{http://\-plg.uwaterloo.ca/\-\textasciitilde cforall/\-Conversions/\-index.html}},
     1688    month       = {Nov},
     1689    year        = {2002},
     1690    urldate     = {28 July 2016},
     1691}
    16471692
    16481693@techreport{Dijkstra65,
    … …  
    16621707    author      = {Christopher D. Marlin},
    16631708    title       = {Coroutines: A Programming Methodology, a Language Design and an Implementation},
    1664     publisher   = {Springer-Verlag},
     1709    publisher   = {Springer},
     1710    address     = {New York},
    16651711    year        = 1980,
    16661712    volume      = 95,
    … …  
    16991745    publisher   = {Benjamin Cummings},
    17001746    year        = 1991,
     1747}
     1748
     1749@article{Moore75,
     1750    keywords    = {approximation methods, integrated circuits},
     1751    contributer = {pabuhr@plg},
     1752    author      = {Gordon E. Moore},
     1753    title       = {Progress in Digital Integrated Electronics},
     1754    journal     = {Technical Digest, International Electron Devices Meeting, IEEE},
     1755    year        = 1975,
     1756    pages       = {11-13},
    17011757}
    17021758
    … …  
    18401896    title       = {The Definition of Standard {ML}},
    18411897    publisher   = {MIT Press},
    1842     address     = {Cambridge, Massachusetts, U.S.A.},
     1898    address     = {Cambridge},
    18431899    year        = 1990
    18441900}
    … …  
    18701926    author      = {Peter A. Buhr and David Dice and Wim H. Hesselink},
    18711927    title       = {Dekker's Mutual Exclusion Algorithm Made RW-Safe},
    1872     journal     = {Concurrency and Computation: Practice and Experience},
     1928    journal     = ccpe,
    18731929    volume      = 28,
    18741930    number      = 1,
    … …  
    19201976    title       = {The Design and Evolution of {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    19211977    publisher   = {Addison-Wesley},
     1978    address     = {Boston},
    19221979    year        = 1994
    19231980}
    … …  
    19772034    author      = {G. Motet and A. Mapinard and J. C. Geoffroy},
    19782035    title       = {Design of Dependable {A}da Software},
    1979     publisher   = {Prentice Hall},
     2036    publisher   = {Prentice-Hall},
     2037    address     = {Englewood Cliffs},
    19802038    year        = 1996,
    19812039}
    … …  
    20122070    title       = {Design Patterns: Elements of Reusable Object-Oriented Software},
    20132071    publisher   = {Addison-Wesley},
     2072    address     = {Boston},
    20142073    year        = 1995,
    20152074    series      = {Professional Computing Series},
    … …  
    20542113    author      = {Ralph E. Johnson and Brian Foote},
    20552114    title       = {Designing Reusable Classes},
    2056     journal     = {Journal of Object-Oriented Programming},
     2115    journal     = joop,
    20572116    year        = 1988,
    20582117    volume      = 1, number = 2, pages = {22-35},
    … …  
    21092168    title       = {A Discipline of Programming},
    21102169    publisher   = {Prentice-Hall},
     2170    address     = {Englewood Cliffs},
    21112171    year        = 1976,
    21122172}
    … …  
    21252185    title       = {Distributed Systems: Principles and Paradigms},
    21262186    publisher   = {Prentice-Hall},
     2187    address     = {Englewood Cliffs},
    21272188    year        = 2002,
    21282189}
    … …  
    22532314    title       = {Eiffel: The Language},
    22542315    publisher   = {Prentice-Hall},
     2316    address     = {Englewood Cliffs},
    22552317    year        = 1992,
    2256     series      = {Prentice Hall Object-Oriented Series},
     2318    series      = {Prentice-Hall Object-Oriented Series},
    22572319}
    22582320
    … …  
    23882450    month       = jun,
    23892451    year        = 2015,
    2390     note        = {\href{http://www.erlang.org/doc/pdf/otp-system-documentation.pdf}{\textsf{http://www.erlang.org/\-doc/\-pdf/\-otp-system-documentation.pdf}}},
     2452    note        = {\href{http://www.erlang.org/doc/pdf/otp-system-documentation.pdf}{\textsf{http://www.erlang.org/\-doc/\-pdf/\-otp-system-\-documentation.pdf}}},
    23912453}
    23922454
    … …  
    24672529    booktitle   = {Advances in COMPUTERS},
    24682530    publisher   = {Academic Press},
     2531    address     = {London},
    24692532    volume      = 56,
    24702533    year        = 2002,
    … …  
    25612624    title       = {Exception Handling in Parallel Computations},
    25622625    journal     = sigplan,
     2626    publisher   = {ACM},
     2627    address     = {New York, NY, USA},
    25632628    volume      = 20,
    25642629    number      = 10,
    25652630    month       = oct,
    25662631    year        = 1985,
    2567     issn        = {0362-1340},
    25682632    pages       = {95-104},
    2569     url         = {http://doi.acm.org/10.1145/382286.382385},
    2570     doi         = {http://doi.acm.org/10.1145/382286.382385},
    2571     acmid       = {382385},
    2572     publisher   = {ACM},
    2573     address     = {New York, NY, USA},
    25742633}
    25752634
    … …  
    26802739    title       = {Fault Tolerance and Exception Handling in {BETA}},
    26812740    booktitle   = {Exception Handling},
    2682     publisher   = {Springer-Verlag},
     2741    publisher   = {Springer},
    26832742    volume      = 2022,
    26842743    series      = {Lecture Notes in Computer Science},
    … …  
    28392898    title       = {A Fully Object-Oriented Exception Handling System: Rationale and Smalltalk Implementation},
    28402899    booktitle   = {Exception Handling},
    2841     publisher   = {Springer-Verlag},
     2900    publisher   = {Springer},
    28422901    volume      = 2022,
    28432902    series      = {Lecture Notes in Computer Science},
    … …  
    28592918    series      = {The Art of Computer Programming},
    28602919    publisher   = {Addison-Wesley},
     2920    address     = {Boston},
    28612921    year        = 1973,
    28622922    volume      = 1,
    2863     edition     = {second},
     2923    edition     = {2nd},
    28642924}
    28652925
    … …  
    29122972    author      = {Richard M. Stallman},
    29132973    organization= {Free Software Foundation},
    2914     address     = {Cambridge, MA}
     2974    address     = {Cambridge}
    29152975}
    29162976
    … …  
    29523012}
    29533013
    2954 
    29553014@article{Haskell,
    29563015    keywords    = {lazy evaluation, type class},
    … …  
    29733032    organization= {Google},
    29743033    year        = 2009,
    2975     note        = {\href{http://golang.org/ref/spec}{http://golang.org/\-ref/\-spec}},
     3034    note        = {\href{http://golang.org/ref/spec}{http://\-golang.org/\-ref/\-spec}},
    29763035}
    29773036
    … …  
    30903149    author      = {Robert E. Strom and David F. Bacon and Arthur P. Goldberg and Andy Lowry and Daniel M. Yellin and Shaula Alexander Yemini},
    30913150    title       = {Hermes: A Language for Distributed Computing},
    3092     publisher   = {Prentice Hall},
     3151    publisher   = {Prentice-Hall},
     3152    address     = {Englewood Cliffs},
    30933153    series      = {Innovative Technology},
    30943154    year        = 1991,
    … …  
    31343194    author      = {Peter A. Buhr and David Dice and Wim H. Hesselink},
    31353195    title       = {High-Performance {$N$}-Thread Software Solutions for Mutual Exclusion},
    3136     journal     = {Concurrency and Computation: Practice and Experience},
     3196    journal     = ccpe,
    31373197    volume      = 27,
    31383198    number      = 3,
    … …  
    31483208    title       = {Zum Hilbertschen Aufbau der reellen Zahlen},
    31493209    publisher   = {Springer},
    3150     journal     = {Mathematische Annalen},
     3210    journal     = mathann,
    31513211    number      = 1,
    31523212    volume      = 99,
    … …  
    31873247    title       = {The Icon Programming Language},
    31883248    publisher   = {Prentice-Hall},
     3249    address     = {Englewood Cliffs},
    31893250    year        = 1983,
    31903251}
    … …  
    32623323    issn        = {0164-0925},
    32633324    pages       = {1270--1343},
    3264     doi         = {http://doi.acm.org/10.1145/1108970.1108975},
    32653325    publisher   = {ACM Press},
    32663326    address     = {New York, NY, USA},
    … …  
    32773337    pages       = {55-59},
    32783338    issn        = {0163-5719},
    3279     doi         = {http://doi.acm.org/10.1145/872736.806932},
    3280  }
     3339}
    32813340
    32823341@book{Algol68,
    … …  
    33613420    title       = {Interacting Processes: A Multiparty Approach to Coordinated Distributed Programming},
    33623421    publisher   = {Addison-Wesley},
     3422    address     = {Boston},
    33633423    series      = {ACM Press Books},
    33643424    year        = 1996,
    … …  
    34343494    title       = {Introduction to Algorithms},
    34353495    publisher   = {MIT Press/McGraw-Hill},
     3496    address     = {Cambridge},
    34363497    series      = {Electrical Engineering and Computer Science Series},
    34373498    year        = 1992,
    … …  
    34443505    title       = {Introduction to Automata Theory, Languages and Computation},
    34453506    publisher   = {Addison-Wesley},
     3507    address     = {Boston},
    34463508    year        = 1979,
    34473509}
    … …  
    34763538    title       = {An Introduction to Operating Systems},
    34773539    publisher   = {Addison-Wesley},
     3540    address     = {Boston},
    34783541    year        = 1990,
    3479     edition     = {second},
     3542    edition     = {2nd},
    34803543}
    34813544
    … …  
    35253588    title       = {Issues with Exception Hnadling in Object-Oriented Systems},
    35263589    booktitle   = {ECOOP'97},
    3527     publisher   = {Springer-Verlag},
     3590    publisher   = {Springer},
    35283591    volume      = 1241,
    35293592    series      = {Lecture Notes in Computer Science},
    … …  
    35533616    title       = {The {Java} Language Specification},
    35543617    publisher   = {Addison-Wesley},
     3618    address     = {Reading},
    35553619    year        = 2000,
    3556     edition     = {second},
     3620    edition     = {2nd},
    35573621}
    35583622
    … …  
    35973661    title       = {Konstruktion nichtrekursiver Funktionen},
    35983662    publisher   = {Springer},
    3599     journal     = {Mathematische Annalen},
     3663    journal     = mathann,
    36003664    number      = 111,
    36013665    volume      = 1,
    … …  
    37403804    title       = {Lisp 1.5 Primer},
    37413805    publisher   = {Dickenson Publishing},
     3806    address     = {Belmont},
    37423807    year        = 1967,
    37433808}
    … …  
    39374002    booktitle   = {Proceedings of the European Conference on Object Oriented Programming},
    39384003    organization= {ECOOP'88},
    3939     publisher   = {Springer-Verlag},
     4004    publisher   = {Springer},
    39404005    volume      = 322,
    39414006    editor      = {S. Gjessing and K. Nygaard},
    … …  
    39794044    title       = {Modern C++ Design: Generic Programming and Design Patterns Applied},
    39804045    publisher   = {Addison-Wesley Professional},
     4046    address     = {Boston},
    39814047    month       = feb,
    39824048    year        = 2001,
    … …  
    39904056    title       = {Modern Operating Systems},
    39914057    publisher   = {Prentice-Hall},
     4058    address     = {Englewood Cliffs},
    39924059    year        = 1992,
    39934060}
    … …  
    43104377    title       = {Nesting in an Object Oriented Language is NOT for the Birds},
    43114378    booktitle   = {Proceedings of the European Conference on Object Oriented Programming},
    4312     publisher   = {Springer-Verlag},
     4379    publisher   = {Springer},
    43134380    volume      = 322,
    43144381    editor      = {S. Gjessing and K. Nygaard},
    … …  
    44374504    editor      = {S. Gjessing and K. Nygaard},
    44384505    organization= {DND, The Norwegian Computer Society},
    4439     publisher   = {Springer-Verlag},
     4506    publisher   = {Springer},
    44404507    comment     = {
    44414508           Objectives:
    … …  
    44724539    title       = {Object-oriented programming; an evolutionary approach},
    44734540    publisher   = {Addison-Wesley},
     4541    address     = {Boston},
    44744542    year        = 1986
    44754543}
    … …  
    44814549    title       = {Object-oriented Programming in the {BETA} Programming Language},
    44824550    publisher   = {Addison-Wesley},
     4551    address     = {Boston},
    44834552    year        = 1993,
    44844553}
    … …  
    45124581    author      = {Bertrand Meyer},
    45134582    title       = {Object-oriented Software Construction},
    4514     publisher   = {Prentice Hall},
     4583    publisher   = {Prentice-Hall},
     4584    address     = {Englewood Cliffs},
    45154585    year        = {1988},
    4516     series      = {Prentice Hall International Series in Computer Science},
     4586    series      = {Prentice-Hall International Series in Computer Science},
    45174587}
    45184588
    … …  
    45414611    author      = {John Galletly},
    45424612    title       = {{OCCAM} 2: Including {OCCAM} 2.1},
    4543     publisher   = {{UCL} (University College London) Press Ltd.},
    4544     edition     = {second},
     4613    publisher   = {{UCL} (University College London) Press},
     4614    address     = {London},
     4615    edition     = {2nd},
    45454616    year        = 1996,
    45464617}
    … …  
    46024673    month       = jul,
    46034674    year        = 2013,
    4604     note        = {\href{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}{\textsf{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}}},
     4675    note        = {\href{http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf}{\textsf{http://\-www.openmp.org/\-mp-documents/\-OpenMP4.0.0.pdf}}},
    46054676}
    46064677
    … …  
    46114682    title       = {Operating Systems},
    46124683    publisher   = {Pearson Prentice-Hall},
     4684    address     = {Englewood Cliffs},
    46134685    year        = 2004,
    4614     edition     = {third},
     4686    edition     = {3rd},
    46154687}
    46164688
    … …  
    46214693    title       = {Operating Systems: Internals and Design Principles},
    46224694    publisher   = {Prentice-Hall},
     4695    address     = {Englewood Cliffs},
    46234696    year        = 1998,
    4624     edition     = {third},
     4697    edition     = {3rd},
    46254698}
    46264699
    … …  
    46314704    title       = {Operating Systems: Internals and Design Principles},
    46324705    publisher   = {Prentice-Hall},
     4706    address     = {Englewood Cliffs},
    46334707    year        = 2001,
    4634     edition     = {fourth},
     4708    edition     = {4th},
    46354709}
    46364710
    … …  
    46414715    title       = {Operating System Concepts},
    46424716    publisher   = {Addision-Wesley},
     4717    address     = {Boston},
    46434718    year        = 1991,
    4644     edition     = {third},
     4719    edition     = {3rd},
    46454720}
    46464721
    … …  
    46514726    title       = {Operating Systems : Design and Implementation},
    46524727    publisher   = {Prentice-Hall},
     4728    address     = {Englewood Cliffs},
    46534729    series      = {Software Series},
    46544730    year        = 1987,
    … …  
    46614737    title       = {Operating System Principles},
    46624738    publisher   = {Prentice-Hall},
     4739    address     = {Englewood Cliffs},
    46634740    year        = 1973,
    46644741}
    … …  
    46704747    title       = {Operating System Principles},
    46714748    publisher   = {Prentice-Hall},
     4749    address     = {Englewood Cliffs},
    46724750    year        = 2003,
    46734751}
    … …  
    46864764
    46874765@article{Ganzinger80,
    4688         contributer = {a3moss@uwaterloo.ca},
    4689         author = {Ganzinger, Harald and Ripken, Knut},
    4690         title = {Operator Identification in {ADA}: Formal Specification, Complexity, and Concrete Implementation},
    4691         journal = {SIGPLAN Notices},
    4692         issue_date = {February 1980},
    4693         volume = {15},
    4694         number = {2},
    4695         month = feb,
    4696         year = {1980},
    4697         issn = {0362-1340},
    4698         pages = {30--42},
    4699         numpages = {13},
    4700         url = {http://doi.acm.org/10.1145/947586.947589},
    4701         doi = {10.1145/947586.947589},
    4702         publisher = {ACM},
    4703         address = {New York, NY, USA}
     4766    contributer = {a3moss@uwaterloo.ca},
     4767    author      = {Ganzinger, Harald and Ripken, Knut},
     4768    title       = {Operator Identification in {ADA}: Formal Specification, Complexity, and Concrete Implementation},
     4769    journal     = {SIGPLAN Notices},
     4770    issue_date  = {February 1980},
     4771    volume      = {15},
     4772    number      = {2},
     4773    month       = feb,
     4774    year        = {1980},
     4775    issn        = {0362-1340},
     4776    pages       = {30--42},
     4777    numpages    = {13},
     4778    url         = {http://doi.acm.org/10.1145/947586.947589},
     4779    doi         = {10.1145/947586.947589},
     4780    publisher   = {ACM},
     4781    address     = {New York, NY, USA}
    47044782}
    47054783
    … …  
    47234801    title       = {{OS} and {DOS} {PL/I} Reference Manual},
    47244802    organization= {International Business Machines},
    4725     edition     = {first},
     4803    edition     = {1st},
    47264804    month       = sep,
    47274805    year        = 1981,
    … …  
    48434921    booktitle   = {Parallel Programming in {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    48444922    publisher   = {MIT Press},
    4845     address     = {Cambridge, MA, USA},
     4923    address     = {Cambridge},
    48464924    series      = {Scientific and Engineering Computation Series},
    48474925    pages       = {507-546},
    … …  
    49225000    publisher   = {Springer--Verlag},
    49235001    year        = 1985,
    4924     edition     = {third},
     5002    edition     = {3rd},
    49255003    note        = {Revised by Andrew B. Mickel and James F. Miner, ISO Pascal Standard}
    49265004}
    … …  
    49335011    publisher   = {Springer--Verlag},
    49345012    year        = 1975,
    4935     edition     = {first},
     5013    edition     = {1st},
    49365014}
    49375015
    … …  
    49555033    title       = {{P}ascal/{VS} Language Reference Manual},
    49565034    organization= {International Business Machines},
    4957     edition     = {first},
     5035    edition     = {1st},
    49585036    year        = 1981,
    49595037    note        = {Manual SH20-6168-1},
    … …  
    51075185    title       = {Principles of Concurrent Programming},
    51085186    publisher   = {Prentice-Hall International},
     5187    address     = {Englewood Cliffs},
    51095188    year        = 1982,
    51105189}
    … …  
    51145193    title       = {Principles of Programming Languages},
    51155194    publisher   = {Prentice-Hall International},
     5195    address     = {Englewood Cliffs},
    51165196    year        = 1981,
    51175197    series      = {Series in Computer Science}
    … …  
    51855265    title       = {Programming with {POSIX} Threads},
    51865266    publisher   = {Addison-Wesley},
     5267    address     = {Boston},
    51875268    series      = {Professional Computing},
    51885269    year        = 1997,
    … …  
    51945275    author      = {J. T. Schwartz and R. B. K. Dewar and E. Dubinsky and E. Schonberg},
    51955276    title       = {Programming with Sets: An Introduction to {SETL}},
    5196     publisher   = {Springer-Verlag},
     5277    publisher   = {Springer},
    51975278    year        = 1986,
    51985279}
    … …  
    52355316    key         = {C++14},
    52365317    title       = {Programming Languages -- {C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    5237     edition     = {fourth},
     5318    edition     = {4th},
    52385319    organization= {International Standard ISO/IEC 14882:2014 (E)},
    52395320    publisher   = {International Standard Organization},
    … …  
    53295410    author      = {Niklaus Wirth},
    53305411    title       = {Programming in Modula-2},
    5331     publisher   = {Springer-Verlag},
     5412    publisher   = {Springer},
     5413    address     = {New York},
    53325414    year        = 1988,
    5333     edition     = {fourth},
     5415    edition     = {4th},
    53345416    series      = {Texts and Monographs in Computer Science},
    53355417}
    … …  
    53435425    month       = feb,
    53445426    year        = 1983,
    5345     note        = {Published by Springer-Verlag}
     5427    note        = {Springer, New York},
    53465428}
    53475429
    … …  
    53515433    title       = {The Programming Language {Ada}: Reference Manual},
    53525434    organization= {United States Department of Defense},
    5353     publisher   = {Springer-Verlag},
     5435    publisher   = {Springer},
    53545436    year        = 1981
    53555437}
    … …  
    55055587
    55065588@article{Grossman06,
    5507  keywords = {Cyclone, existential types, polymorphism, type variables},
    5508  contributer = {a3moss@plg},
    5509  author = {Grossman, Dan},
    5510  title = {Quantified Types in an Imperative Language},
    5511  journal = toplas,
    5512  issue_date = {May 2006},
    5513  volume = {28},
    5514  number = {3},
    5515  month = may,
    5516  year = {2006},
    5517  issn = {0164-0925},
    5518  pages = {429--475},
    5519  numpages = {47},
    5520  url = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/1133651.1133653},
    5521  doi = {10.1145/1133651.1133653},
    5522  acmid = {1133653},
    5523  publisher = {ACM},
    5524  address = {New York, NY, USA},
     5589    keywords    = {Cyclone, existential types, polymorphism, type variables},
     5590    contributer = {a3moss@plg},
     5591    author      = {Grossman, Dan},
     5592    title       = {Quantified Types in an Imperative Language},
     5593    journal     = toplas,
     5594    issue_date  = {May 2006},
     5595    volume      = {28},
     5596    number      = {3},
     5597    month       = may,
     5598    year        = {2006},
     5599    issn        = {0164-0925},
     5600    pages       = {429--475},
     5601    numpages    = {47},
     5602    url         = {http://doi.acm.org.proxy.lib.uwaterloo.ca/10.1145/1133651.1133653},
     5603    doi         = {10.1145/1133651.1133653},
     5604    acmid       = {1133653},
     5605    publisher   = {ACM},
     5606    address     = {New York, NY, USA},
    55255607}
    55265608
    … …  
    55695651    title       = {{A}da Reference Manual},
    55705652    edition     = {International Standard {ISO}/{IEC} {8652:1995(E)} with {COR.1:2000}},
    5571     organization = {Intermetrics, Inc.},
     5653    organization= {Intermetrics, Inc.},
    55725654    month       = dec,
    55735655    year        = 1995,
    … …  
    55795661    contributer = {pabuhr@plg},
    55805662    title       = {Programming languages -- {Ada}},
    5581     edition     = {third},
     5663    edition     = {3rd},
    55825664    organization= {International Standard ISO/IEC 1989:2014},
    55835665    publisher   = {International Standard Organization},
    … …  
    56045686    series      = {The Real-Time for Java Expert Group, {\small\textsf{http://\-www.rtj.org}}},
    56055687    publisher   = {Addison-Wesley},
     5688    address     = {Boston},
    56065689    year        = 2000,
    56075690}
    … …  
    57555838% S
    57565839
     5840@manual{Scala,
     5841    keywords    = {Scala programming language},
     5842    contributer = {pabuhr@plg},
     5843    title       = {{Scala} Language Specification, Version 2.11},
     5844    organization= {\'{E}cole Polytechnique F\'{e}d\'{e}rale de Lausanne},
     5845    year        = 2016,
     5846    note        = {\href{http://www.scala-lang.org/files/archive/spec/2.11}{http://\-www.scala-lang.org/\-files/\-archive/\-spec/\-2.11}},
     5847}
     5848
    57575849@inproceedings{Michael04,
    57585850    keywords    = {lock free, dynamic memory allocation},
    … …  
    58025894    pages       = {51-67},
    58035895    editor      = {G. Kahn and D. B. MacQueen and G. D. Plotkin},
    5804     publisher   = {Springer-Verlag},
     5896    publisher   = {Springer},
    58055897    note        = {Lecture Notes in Computer Science v. 173},
    58065898}
    … …  
    58525944    month       = may,
    58535945    year        = 2001,
    5854     note        = {{\small\textsf{http://www.python.org/peps/pep-0255.html}}},
     5946    note        = {\href{http://www.python.org/peps/pep-0255.html}{http://\-www.python.org/\-peps/\-pep-0255.html}},
    58555947}
    58565948
    … …  
    58715963
    58725964@article{Pennello80,
    5873         contributer = {a3moss@uwaterloo.ca},
    5874         author = {Pennello, Tom and DeRemer, Frank and Meyers, Richard},
    5875         title = {A Simplified Operator Identification Scheme for {Ada}},
    5876         journal = {SIGPLAN Notices},
    5877         issue_date = {July-August 1980},
    5878         volume = {15},
    5879         number = {7 and 8},
    5880         month = jul,
    5881         year = {1980},
    5882         issn = {0362-1340},
    5883         pages = {82--87},
    5884         numpages = {6},
    5885         url = {http://doi.acm.org/10.1145/947680.947688},
    5886         doi = {10.1145/947680.947688},
    5887         publisher = {ACM},
    5888         address = {New York, NY, USA},
     5965    contributer = {a3moss@uwaterloo.ca},
     5966    author      = {Pennello, Tom and DeRemer, Frank and Meyers, Richard},
     5967    title       = {A Simplified Operator Identification Scheme for {Ada}},
     5968    journal     = {SIGPLAN Notices},
     5969    issue_date  = {July-August 1980},
     5970    volume      = {15},
     5971    number      = {7 and 8},
     5972    month       = jul,
     5973    year        = {1980},
     5974    issn        = {0362-1340},
     5975    pages       = {82--87},
     5976    numpages    = {6},
     5977    url         = {http://doi.acm.org/10.1145/947680.947688},
     5978    doi         = {10.1145/947680.947688},
     5979    publisher   = {ACM},
     5980    address     = {New York, NY, USA},
    58895981}
    58905982
    … …  
    59276019    year        = {1980},
    59286020    address     = {Lund, Sweden},
    5929     edition     = {second},
     6021    edition     = {2nd},
    59306022}
    59316023
    59326024@book{Simula67,
    5933     author      = "O-J Dahl and B. Myhrhaug and K. Nygaard",
    5934     address     = "Oslo Norway",
     6025    author      = {O-J Dahl and B. Myhrhaug and K. Nygaard},
     6026    title       = {Simula67 Common Base Language},
    59356027    month       = oct,
    59366028    year        = 1970,
    5937     publisher   = "Norwegian Computing Center",
    5938     title       = "Simula67 Common Base Language"
     6029    publisher   = {Norwegian Com\-puting Center},
     6030    address     = {Oslo Norway},
    59396031}
    59406032
    … …  
    59456037    title       = {Smalltalk-80: The Language and its Implementation},
    59466038    publisher   = {Addison-Wesley},
     6039    address     = {Reading},
    59476040    year        = 1983
    59486041}
    … …  
    59666059    author      = {R. E. Griswold and J. F. Poage and I. P. Polonsky},
    59676060    title       = {The SNOBOL4 Programming Language},
    5968     edition     = {second},
     6061    edition     = {2nd},
    59696062    publisher   = {Prentice-Hall},
     6063    address     = {Englewood Cliffs},
    59706064    year        = 1971,
    59716065}
    … …  
    60736167    author      = {R. H. Campbell and A. N. Habermann},
    60746168    title       = {The Specification of Process Synchronization by Path Expressions},
    6075     publisher   = {Springer-Verlag},
     6169    publisher   = {Springer},
    60766170    year        = 1974,
    60776171    volume      = 16,
    … …  
    61176211    title       = {A Standard {ML} Compiler},
    61186212    booktitle   = {Functional Programming Languages and Computer Architecture},
    6119     publisher   = {Springer-Verlag},
     6213    publisher   = {Springer},
    61206214    series      = {Lecture Notes in Computer Science},
    61216215    volume      = 274,
    … …  
    61726266    title       = {Structured Concurrent Programming with Operating System Applications},
    61736267    publisher   = {Addison-Wesley},
     6268    address     = {Boston},
    61746269    year        = 1978,
    61756270}
    … …  
    63206415    author      = {Gadi Taubenfeld},
    63216416    title       = {Synchronization Algorithms and Concurrent Programming},
    6322     publisher   = {Pearson/Prentice Hall},
     6417    publisher   = {Pearson/Prentice-Hall},
     6418    address     = {Harlow, England},
    63236419    year        = 2006,
    63246420}
    … …  
    63806476    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},
    63816477    title       = {Systems Programming with Modula-3},
    6382     publisher   = {Prentice-Hall, Inc.},
     6478    publisher   = {Prentice-Hall},
     6479    address     = {Englewood Cliffs},
    63836480    year        = 1991,
    6384     series      = {Prentice Hall Series in Innovative Technology}
     6481    series      = {Prentice-Hall Series in Innovative Technology}
    63856482}
    63866483
    … …  
    64646561    pages       = {408-423},
    64656562    editor      = {B. Robinet},
    6466     publisher   = {Springer-Verlag},
     6563    publisher   = {Springer},
    64676564    note        = {Lecture Notes in Computer Science, v. 19},
    64686565    abstract    = {
    … …  
    65466643    publisher   = {Holt Software Associates Inc.},
    65476644    year        = 1992,
    6548     edition     = {third},
     6645    edition     = {3rd},
    65496646}
    65506647
    … …  
    65666663    title       = {Tutorial: Programming Language Design},
    65676664    publisher   = {Computer Society Press},
     6665    address     = {Los Alamitos},
    65686666    year        = 1980
    65696667}
    … …  
    66356733% U
    66366734
    6637 @unpublished{uC++book,
    6638     keywords    = {control structure, concurrency},
     6735@book{uC++book,
     6736    keywords    = {control structure, concurrency, uC++},
    66396737    contributer = {pabuhr@plg},
    66406738    author      = {Peter A. Buhr},
    6641     title       = {Understanding Control Flow with Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
    6642     year        = 1999,
    6643     note        = {Textbook in preparation}
     6739    title       = {Understanding Control Flow: Concurrent Programming using $\mu${C}{\kern-.1em\hbox{\large\texttt{+\kern-.25em+}}}},
     6740    publisher   = {Springer},
     6741    address     = {Switzerland},
     6742    year        = 2016,
    66446743}
    66456744
    … …  
    66646763    booktitle   = {Proceedings of the International Workshop on Memory Management},
    66656764    location    = {St. Malo, France},
    6666     publisher   = {Springer-Verlag},
     6765    publisher   = {Springer},
    66676766    series      = {Lecture Notes in Computer Science},
    66686767    volume      = 637,
    … …  
    67886887    title       = {VAX-11 Architecture Reference Manual},
    67896888    publisher   = {Digital Press},
     6889    address     = {Bedford},
    67906890    month       = may,
    67916891    year        = 1982,
    … …  
    67966896    title       = {{VAX/VMS} Internals and Data Structures Version 4.4},
    67976897    publisher   = {Digital Press},
     6898    address     = {Bedford},
    67986899    year        = 1988,
    67996900}
    … …  
    68056906    title       = {Verifying a Simplification of Mutual Exclusion by {L}ycklama--{H}adzilacos},
    68066907    journal     = {Acta Informatica},
    6807     publisher   = {Springer-Verlag},
     6908    publisher   = {Springer},
     6909    address     = {New York},
    68086910    year        = {2013},
    68096911    volume      = {50},
    … …  
    68716973    month       = jun,
    68726974    year        = 1985,
    6873     note        = {\textsf{http://www.hpl.hp.com/\-techreports/\-tandem/\-TR-85.7.pdf}},
     6975    note        = {\href{http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf}{http://www.hpl.hp.com/\-techreports/\-tandem/\-TR-85.7.pdf}},
    68746976}
    68756977

  • doc/proposals/concurrency/concurrency.tex

    r141b786 rb726084  
    11% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    22
    3 % inline code ©...© (copyright symbol) emacs: C-q M-)
    4 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
    5 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    6 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    7 % LaTex escape §...§ (section symbol) emacs: C-q M-'
    8 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
     3% inline code �...� (copyright symbol) emacs: C-q M-)
     4% red highlighting �...� (registered trademark symbol) emacs: C-q M-.
     5% blue highlighting �...� (sharp s symbol) emacs: C-q M-_
     6% green highlighting �...� (cent symbol) emacs: C-q M-"
     7% LaTex escape �...� (section symbol) emacs: C-q M-'
     8% keyword escape �...� (pilcrow symbol) emacs: C-q M-^
    99% math escape $...$ (dollar symbol)
    1010
    … …  
    1414
    1515% Latex packages used in the document.
    16 \usepackage[T1]{fontenc}                                % allow Latin1 (extended ASCII) characters
     16\usepackage[T1]{fontenc}                                        % allow Latin1 (extended ASCII) characters
    1717\usepackage{textcomp}
    1818\usepackage[latin1]{inputenc}
    1919\usepackage{fullpage,times,comment}
    2020\usepackage{epic,eepic}
    21 \usepackage{upquote}                                                                    % switch curled `'" to straight
     21\usepackage{upquote}                                            % switch curled `'" to straight
    2222\usepackage{calc}
    2323\usepackage{xspace}
    … …  
    2525\usepackage{tabularx}
    2626\usepackage[acronym]{glossaries}
    27 \usepackage{varioref}                                                           % extended references
     27\usepackage{varioref}                                           % extended references
    2828\usepackage{inconsolata}
    29 \usepackage{listings}                                                                   % format program code
    30 \usepackage[flushmargin]{footmisc}                                              % support label/reference in footnote
    31 \usepackage{latexsym}                                   % \Box glyph
    32 \usepackage{mathptmx}                                   % better math font with "times"
     29\usepackage{listings}                                           % format program code
     30\usepackage[flushmargin]{footmisc}                              % support label/reference in footnote
     31\usepackage{latexsym}                                           % \Box glyph
     32\usepackage{mathptmx}                                           % better math font with "times"
    3333\usepackage[usenames]{color}
    3434\usepackage[pagewise]{lineno}
    3535\usepackage{fancyhdr}
    3636\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    37 \input{common}                                          % bespoke macros used in the document
     37\input{style}                                                   % bespoke macros used in the document
    3838\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    3939\usepackage{breakurl}
    … …  
    4444\renewcommand{\UrlFont}{\small\sf}
    4545
    46 \setlength{\topmargin}{-0.45in}                                                 % move running title into header
     46\setlength{\topmargin}{-0.45in}                         % move running title into header
    4747\setlength{\headsep}{0.25in}
    4848
    … …  
    8686\title{Concurrency in \CFA}
    8787\author{Thierry Delisle \\
    88 Dept. of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
     88School of Computer Science, University of Waterloo, \\ Waterloo, Ontario, Canada
    8989}
    9090
    9191\maketitle
     92
     93% ### #     # ####### ######  #######
     94%  #  ##    #    #    #     # #     #
     95%  #  # #   #    #    #     # #     #
     96%  #  #  #  #    #    ######  #     #
     97%  #  #   # #    #    #   #   #     #
     98%  #  #    ##    #    #    #  #     #
     99% ### #     #    #    #     # #######
     100
    92101\section{Introduction}
    93 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.
    94 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.
    95 
    96 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.
     102This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build higher-level features. The simplest possible concurrency core is a thread and a lock but this low-level approach is hard to master. An easier approach for users is to support higher-level constructs as the basis of the concurrency in \CFA. Indeed, for highly productive parallel programming, high-level approaches are much more popular~\cite{HPP:Study}. Examples are task based parallelism, message passing and implicit threading.
     103
     104There are actually two problems that need to be solved in the design of the concurrency for a programming language. Which concurrency tools are available to the users and which parallelism tools are available. While these two concepts are often seen together, they are in fact distinct concepts that require different sorts of tools~\cite{Buhr05a}. Concurrency tools need to handle mutual exclusion and synchronization, while parallelism tools are more about performance, cost and resource utilization.
     105
     106%  #####  ####### #     #  #####  #     # ######  ######  ####### #     #  #####  #     #
     107% #     # #     # ##    # #     # #     # #     # #     # #       ##    # #     #  #   #
     108% #       #     # # #   # #       #     # #     # #     # #       # #   # #         # #
     109% #       #     # #  #  # #       #     # ######  ######  #####   #  #  # #          #
     110% #       #     # #   # # #       #     # #   #   #   #   #       #   # # #          #
     111% #     # #     # #    ## #     # #     # #    #  #    #  #       #    ## #     #    #
     112%  #####  ####### #     #  #####   #####  #     # #     # ####### #     #  #####     #
    97113
    98114\section{Concurrency}
    99 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.
    100 \\
    101 
    102 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.
     115Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared state, some languages and libraries simply disallow mutable shared-state (Erlang~\cite{Erlang}, Haskell~\cite{Haskell}, Akka (Scala)~\cite{Akka}). In these paradigms, interaction among concurrent objects relies on message passing~\cite{Thoth,Harmony,V-Kernel} or other paradigms that closely relate to networking concepts. However, in languages that use routine calls as their core abstraction mechanism, these approaches force a clear distinction between concurrent and non-concurrent paradigms (i.e. message passing versus routine call). Which in turn means that, in order to be effective, programmers need to learn two sets of designs patterns. This distinction can be hidden away in library code, but effective use of the librairy will still have to take both paradigms into account. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on non-concurrent constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. Many such mechanisms have been proposed, including semaphores~\cite{Dijkstra68b} and path expressions~\cite{Campbell74}. However, for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm~\cite{HPP:Study}. An approach that is worth mentionning because it is gaining in popularity is transactionnal memory~\cite{Dice10}[Check citation]. While this approach is even pursued by system languages like \CC\cit, the performance and feature set is currently too restrictive to be possible to add such a paradigm to a language like C or \CC\cit, which is why it was rejected as the core paradigm for concurrency in \CFA. One of the most natural, elegant, and efficient mechanisms for synchronization and communication, especially for shared memory systems, is the \emph{monitor}. Monitors were first proposed by Brinch Hansen~\cite{Hansen73} and later described and extended by C.A.R.~Hoare~\cite{Hoare74}. Many programming languages---e.g., Concurrent Pascal~\cite{ConcurrentPascal}, Mesa~\cite{Mesa}, Modula~\cite{Modula-2}, Turing~\cite{Turing:old}, Modula-3~\cite{Modula-3}, NeWS~\cite{NeWS}, Emerald~\cite{Emerald}, \uC~\cite{Buhr92a} and Java~\cite{Java}---provide monitors as explicit language constructs. In addition, operating-system kernels and device drivers have a monitor-like structure, although they often use lower-level primitives such as semaphores or locks to simulate monitors. For these reasons, this project proposes Monitors as the core concurrency construct.
     116
     117% #     # ####### #     # ### ####### ####### ######   #####
     118% ##   ## #     # ##    #  #     #    #     # #     # #     #
     119% # # # # #     # # #   #  #     #    #     # #     # #
     120% #  #  # #     # #  #  #  #     #    #     # ######   #####
     121% #     # #     # #   # #  #     #    #     # #   #         #
     122% #     # #     # #    ##  #     #    #     # #    #  #     #
     123% #     # ####### #     # ###    #    ####### #     #  #####
    103124
    104125\subsection{Monitors}
    105 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 :
     126A 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 :
    106127\begin{lstlisting}
    107128        typedef /*some monitor type*/ monitor;
    … …  
    114135\end{lstlisting}
    115136
     137%  #####     #    #       #
     138% #     #   # #   #       #
     139% #        #   #  #       #
     140% #       #     # #       #
     141% #       ####### #       #
     142% #     # #     # #       #
     143%  #####  #     # ####### #######
     144
    116145\subsubsection{Call semantics} \label{call}
    117 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.
    118 \\
    119 
    120 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 :
     146The above monitor example displays some of their intrinsic characteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because at their core, monitors are implicit mutual-exclusion objects (locks), and these objects cannot be copied. Therefore, monitors are implicitly non-copyable.
     147
     148Another aspect to consider is when a monitor acquires its mutual exclusion. For example, a monitor may need to be passed through multiple helper routines that do not acquire the monitor mutual exclusion on entry. Pass through can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following to implement an atomic large counter :
    121149
    122150\begin{lstlisting}
    … …  
    124152
    125153        void ?{}(counter_t & nomutex this);
    126         int ++?(counter_t & mutex this);
    127         void ?{}(Int * this, counter_t & mutex cnt);
     154        size_t ++?(counter_t & mutex this);
     155
     156        //need for mutex is platform dependent here
     157        void ?{}(size_t * this, counter_t & mutex cnt);
    128158\end{lstlisting}
    129159*semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
    130 \\
    131 
    132 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
    133 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.
    134 \\
    135 
    136 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.
    137 \\
    138 
    139 Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
     160
     161Here, the constructor(\code(?{})) uses the \code{nomutex} keyword to signify that it does not acquire the monitor mutual exclusion when constructing. This semantics is because object not yet constructed should never be shared and therefore do not require mutual exclusion. The prefix increment operator uses \code{mutex} to protect the incrementing process from race conditions. Finally, there is a conversion operator from \code{counter_t} to \code{size_t}. This conversion may or may not require the \code{mutex} key word depending on whether or not reading an \code{size_t} is an atomic operation or not.
     162
     163Having both \code{mutex} and \code{nomutex} keywords could be argued to be redundant based on the meaning of a routine having neither of these keywords. If there were a meaning to routine \code{void foo(counter_t & this)} then one could argue that it should default to the safest option : \code{mutex}. On the other hand, the option of having routine \code{void foo(counter_t & this)} mean \code{nomutex} is unsafe by default and may easily cause subtle errors. It can be argued that this is the more "normal" behavior, \code{nomutex} effectively stating explicitly that "this routine has nothing special". Another alternative is to make having exactly one of these keywords mandatory, which would provide the same semantics but without the ambiguity of supporting routine \code{void foo(counter_t & this)}. Mandatory keywords would also have the added benefice of being self-documented but at the cost of extra typing. In the end, which solution should be picked is still up for debate. For the reminder of this proposal, the explicit approach is used for clarity.
     164
     165Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used as a type qualifier. Consider :
    140166\begin{lstlisting}
    141167        int f1(monitor & mutex m);
    … …  
    146172\end{lstlisting}
    147173
    148 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).
     174The problem is to indentify which object(s) should be acquired. Furthermore, each object needs to be acquired only once. In case of simple routines like \code{f1} and \code{f2} it is easy to identify an exhaustive list of objects to acquire on entering. Adding indirections (\code{f3}) still allows the compiler and programmer to indentify which object is acquired. However, adding in arrays (\code{f4}) makes it much harder. Array lengths are not necessarily known in C and even then making sure we only acquire objects once becomes also none trivial. This can be extended to absurd limits like \code{f5}, which uses a graph of monitors. To keep everyone as sane as possible~\cite{Chicken}, this projects imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter (ignoring potential qualifiers and indirections). Also note that while routine \code{f3} can be supported, meaning that monitor \code{**m} will be acquired, passing an array to this routine would be type safe and result in undefined behavior. For this reason, it would also be reasonnable to disallow mutex in the context where arrays may be passed.
     175
     176% ######     #    #######    #
     177% #     #   # #      #      # #
     178% #     #  #   #     #     #   #
     179% #     # #     #    #    #     #
     180% #     # #######    #    #######
     181% #     # #     #    #    #     #
     182% ######  #     #    #    #     #
    149183
    150184\subsubsection{Data semantics} \label{data}
    … …  
    160194
    161195        int ++?(counter_t & mutex this) {
    162                 return ++this->value;
    163         }
    164 
     196                return ++this.value;
     197        }
     198
     199        //need for mutex is platform dependent here
    165200        void ?{}(int * this, counter_t & mutex cnt) {
    166201                *this = (int)cnt;
    167202        }
    168203\end{lstlisting}
    169 \begin{tabular}{ c c }
    170 Thread 1 & Thread 2 \\
    171 \begin{lstlisting}
    172         void f(counter_t & mutex c) {
    173                 for(;;) {
    174                         sout | (int)c | endl;
    175                 }
    176         }
    177 \end{lstlisting} &\begin{lstlisting}
    178         void g(counter_t & mutex c) {
    179                 for(;;) {
    180                         ++c;
    181                 }
    182         }
    183 
     204
     205This 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 :
     206\begin{center}
     207\begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
     208\begin{lstlisting}
     209        counter_t cnt;
     210
     211        thread 1 : cnt++;
     212        thread 2 : cnt++;
     213        thread 3 : cnt++;
     214          ...
     215        thread N : cnt++;
    184216\end{lstlisting}
    185217\end{tabular}
    186 \\
    187 
    188 
    189 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. \\
     218\end{center}
    190219
    191220These simple mutual exclusion semantics also naturally expand to multi-monitor calls.
    … …  
    198227\end{lstlisting}
    199228
    200 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 :
     229This code acquires both locks before entering the critical section (Referenced as \gls{group-acquire} from now on). In practice, writing multi-locking routines that can not lead to deadlocks can be tricky. Having language support for such a feature is therefore a significant asset for \CFA. In the case presented above, \CFA guarantees that the order of aquisition will be consistent across calls to routines using the same monitors as arguments. However, since \CFA monitors use multi-acquiring locks users can effectively force the acquiring order. For example, notice which routines use \code{mutex}/\code{nomutex} and how this affects aquiring order :
    201230\begin{lstlisting}
    202231        void foo(A & mutex a, B & mutex a) {
    … …  
    217246\end{lstlisting}
    218247
    219 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.
     248Such a use will lead to nested monitor call problems~\cite{Lister77}, which are a specific implementation of the lock acquiring order problem. In the example above, the user uses implicit ordering in the case of function \code{foo} but explicit ordering in the case of \code{bar} and \code{baz}. This subtle mistake means that calling these routines concurrently may lead to deadlocks, depending on the implicit ordering matching the explicit ordering. As shown on several occasion\cit, solving this problems requires to :
     249\begin{enumerate}
     250        \item Dynamically track the monitor call order.
     251        \item Implement rollback semantics.
     252\end{enumerate}
     253
     254While the first requirement is already a significant constraint on the system, implementing a general rollback semantics in a C-like language is prohibitively complex \cit. In \CFA users simply need to be carefull when acquiring multiple monitors at the same time.
     255
     256% ######  ####### #######    #    ### #        #####
     257% #     # #          #      # #    #  #       #     #
     258% #     # #          #     #   #   #  #       #
     259% #     # #####      #    #     #  #  #        #####
     260% #     # #          #    #######  #  #             #
     261% #     # #          #    #     #  #  #       #     #
     262% ######  #######    #    #     # ### #######  #####
     263%
     264%             ######  ####### #       #     # #     # ####### ######  #     #
     265%             #     # #     # #        #   #  ##   ## #     # #     # #     #
     266%             #     # #     # #         # #   # # # # #     # #     # #     #
     267%  #####    ######  #     # #          #    #  #  # #     # ######  #######
     268%             #       #     # #          #    #     # #     # #   #   #     #
     269%             #       #     # #          #    #     # #     # #    #  #     #
     270%             #       ####### #######    #    #     # ####### #     # #     #
    220271
    221272\subsubsection{Implementation Details: Interaction with polymorphism}
    222 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.
    223 
    224 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.
     273At first glance, interaction between monitors and \CFA's concept of polymorphism seem complex to support. However, it can be reasoned that entry-point locking can solve most of the issues that could be present with polymorphism.
     274
     275First of all, interaction between \code{otype} polymorphism and monitors is impossible since monitors do not support copying. Therefore, the main question is how to support \code{dtype} polymorphism. Since a monitor's main purpose is to ensure mutual exclusion when accessing shared data, this implies that mutual exclusion is only required for routines that do in fact access shared data. However, since \code{dtype} polymorphism always handles incomplete types (by definition), no \code{dtype} polymorphic routine can access shared data since the data requires knowledge about the type. Therefore the only concern when combining \code{dtype} polymorphism and monitors is to protect access to routines. \Gls{callsite-locking}\footnotemark would require a significant amount of work, since any \code{dtype} routine may have to obtain some lock before calling a routine, depending on whether or not the type passed is a monitor. However, with \gls{entry-point-locking}\footnotemark[\value{footnote}] calling a monitor routine becomes exactly the same as calling it from anywhere else.
     276\footnotetext{See glossary for a definition of \gls{callsite-locking} and \gls{entry-point-locking}}
     277
     278% ### #     # #######         #####   #####  #     # ####### ######
     279%  #  ##    #    #           #     # #     # #     # #       #     #
     280%  #  # #   #    #           #       #       #     # #       #     #
     281%  #  #  #  #    #            #####  #       ####### #####   #     #
     282%  #  #   # #    #    ###          # #       #     # #       #     #
     283%  #  #    ##    #    ###    #     # #     # #     # #       #     #
     284% ### #     #    #    ###     #####   #####  #     # ####### ######
    225285
    226286\subsection{Internal scheduling} \label{insched}
    227 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 :
     287Monitors also need to schedule waiting threads within it as a mean of synchronization. Internal scheduling is one of the simple examples of such a feature. It allows users to declare condition variables and have threads wait and signaled from them. Here is a simple example of such a technique :
    228288
    229289\begin{lstlisting}
    … …  
    243303\end{lstlisting}
    244304
    245 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.
    246 
     305Here routine \code{foo} waits for the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This semantic can easily be extended to multi-monitor calls by offering the same guarantee.
    247306\begin{center}
    248307\begin{tabular}{ c @{\hskip 0.65in} c }
    … …  
    250309\begin{lstlisting}
    251310void foo(monitor & mutex a,
    252          monitor & mutex b) {
     311           monitor & mutex b) {
    253312        //...
    254313        wait(a.e);
    … …  
    259318\end{lstlisting} &\begin{lstlisting}
    260319void bar(monitor & mutex a,
    261          monitor & mutex b) {
     320           monitor & mutex b) {
    262321        signal(a.e);
    263322}
    … …  
    269328\end{tabular}
    270329\end{center}
    271 
    272 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):
     330A direct extension of the single monitor semantics is 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. It is possible to support internal scheduling and \gls{group-acquire} without any extra syntax by relying on order of acquisition. Here is an example of the different contexts in which internal scheduling can be used. (Note that here the use of helper routines is irrelevant, only routines acquire mutual exclusion have an impact on internal scheduling):
    273331
    274332\begin{center}
    … …  
    280338
    281339void foo(monitor & mutex a,
    282          monitor & mutex b) {
     340           monitor & mutex b) {
     341
    283342        wait(e);
    284343}
    … …  
    294353
    295354void bar(monitor & mutex a,
    296          monitor & nomutex b) {
     355           monitor & nomutex b) {
    297356        foo(a,b);
    298357}
    299358
    300359void foo(monitor & mutex a,
    301          monitor & mutex b) {
     360           monitor & mutex b) {
    302361        wait(e);
    303362}
    … …  
    308367
    309368void bar(monitor & mutex a,
    310          monitor & nomutex b) {
    311         foo(a,b);
     369           monitor & nomutex b) {
     370        baz(a,b);
    312371}
    313372
    314373void baz(monitor & nomutex a,
    315          monitor & mutex b) {
     374           monitor & mutex b) {
    316375        wait(e);
    317376}
    … …  
    322381\end{center}
    323382
    324 This can be interpreted in two different ways :
    325 \begin{flushleft}
    326 \begin{enumerate}
    327         \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{ignoring} nested calls.
    328         \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{considering} nested calls.
    329 \end{enumerate}
    330 \end{flushleft}
    331 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. :
     383Note that in \CFA, \code{condition} have no particular need to be stored inside a monitor, beyond any software engineering reasons. Context 1 is the simplest way of acquiring more than one monitor (\gls{group-acquire}), using a routine wiht multiple parameters having the \code{mutex} keyword. Context 2 also uses \gls{group-acquire} as well in routine \code{foo}. However, the routine is called by routine \code{bar} which only acquires monitor \code{a}. Since monitors can be acquired multiple times this will not cause a deadlock by itself but it does force the acquiring order to \code{a} then \code{b}. Context 3 also forces the acquiring order to be \code{a} then \code{b} but does not use \gls{group-acquire}. The previous example tries to illustrate the semantics that must be established to support releasing monitors in a \code{wait} statement. In all cases the behavior of the wait statment is to release all the locks that were acquired my the inner-most monitor call. That is \code{a & b} in context 1 and 2 and \code{b} only in context 3. Here are a few other examples of this behavior.
     384
    332385
    333386\begin{center}
    334 \begin{tabular}{c @{\hskip 0.35in} c @{\hskip 0.35in} c}
    335 \begin{lstlisting}
    336 enterMonitor(a);
    337 enterMonitor(b);
    338 // do stuff
    339 leaveMonitor(b);
    340 leaveMonitor(a);
    341 \end{lstlisting} & != &\begin{lstlisting}
    342 enterMonitor(a);
    343 enterMonitor(a, b);
    344 // do stuff
    345 leaveMonitor(a, b);
    346 leaveMonitor(a);
     387\begin{tabular}{|c|c|c|}
     388\begin{lstlisting}
     389condition e;
     390
     391//acquire a
     392void foo(monitor & nomutex a,
     393           monitor & mutex b) {
     394        bar(a,b);
     395}
     396
     397//acquire a
     398void bar(monitor & mutex a,
     399           monitor & nomutex b) {
     400
     401        //release a
     402        //keep b
     403        wait(e);
     404}
     405
     406foo(a, b);
     407\end{lstlisting} &\begin{lstlisting}
     408condition e;
     409
     410//acquire a & b
     411void foo(monitor & mutex a,
     412           monitor & mutex b) {
     413        bar(a,b);
     414}
     415
     416//acquire b
     417void bar(monitor & mutex a,
     418           monitor & nomutex b) {
     419
     420        //release b
     421        //keep a
     422        wait(e);
     423}
     424
     425foo(a, b);
     426\end{lstlisting} &\begin{lstlisting}
     427condition e;
     428
     429//acquire a & b
     430void foo(monitor & mutex a,
     431           monitor & mutex b) {
     432        bar(a,b);
     433}
     434
     435//acquire none
     436void bar(monitor & nomutex a,
     437           monitor & nomutex b) {
     438
     439        //release a & b
     440        //keep none
     441        wait(e);
     442}
     443
     444foo(a, b);
    347445\end{lstlisting}
    348446\end{tabular}
    349447\end{center}
    350 
    351 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.
     448Note the right-most example which uses a helper routine and therefore is not relevant to find which monitors will be released.
     449
     450These semantics imply that in order to release of subset of the monitors currently held, users must write (and name) a routine that only acquires the desired subset and simply calls wait. While users can use this method, \CFA offers the \code{wait_release}\footnote{Not sure if an overload of \code{wait} would work...} which will release only the specified monitors.
     451
     452Regardless of the context in which the \code{wait} statement is used, \code{signal} must used holding the same set of monitors. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) that call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
     453
     454Finally, an additional semantic which can be very usefull is the \code{signal_block} routine. This routine behaves like signal for all of the semantics discussed above, but with the subtelty that mutual exclusion is transferred to the waiting task immediately rather than wating for the end of the critical section.
    352455\\
    353456
    354 The following examples shows three alternatives of explicit wait semantics :
    355 \\
    356 
    357 \begin{center}
    358 \begin{tabular}{|c|c|c|}
    359 Case 1 & Case 2 & Case 3 \\
    360 Branding on construction & Explicit release list & Explicit ignore list \\
    361 \hline
    362 \begin{lstlisting}
    363 void foo(monitor & mutex a,
    364          monitor & mutex b,
    365            condition & c)
    366 {
    367         // Releases monitors
    368         // branded in ctor
    369         wait(c);
    370 }
    371 
    372 monitor a;
    373 monitor b;
    374 condition1 c1 = {a};
    375 condition2 c2 = {a, b};
    376 
    377 //Will release only a
    378 foo(a,b,c1);
    379 
    380 //Will release a and b
    381 foo(a,b,c2);
    382 \end{lstlisting} &\begin{lstlisting}
    383 void foo(monitor & mutex a,
    384          monitor & mutex b,
    385            condition & c)
    386 {
    387         // Releases monitor a
    388         // Holds monitor b
    389         waitRelease(c, [a]);
    390 }
    391 
    392 monitor a;
    393 monitor b;
    394 condition c;
    395 
    396 
    397 
    398 foo(a,b,c);
    399 
    400 
    401 
    402 \end{lstlisting} &\begin{lstlisting}
    403 void foo(monitor & mutex a,
    404          monitor & mutex b,
    405            condition & c)
    406 {
    407         // Releases monitor a
    408         // Holds monitor b
    409         waitHold(c, [b]);
    410 }
    411 
    412 monitor a;
    413 monitor b;
    414 condition c;
    415 
    416 
    417 
    418 foo(a,b,c);
    419 
    420 
    421 
    422 \end{lstlisting}
    423 \end{tabular}
    424 \end{center}
    425 (Note : Case 2 and 3 use tuple semantics to pass a variable length list of elements.)
    426 \\
    427 
    428 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 :
    429 \begin{lstlisting}
    430 void wait(condition & cond) {
    431         waitHold(cond, []);
    432 }
    433 \end{lstlisting}
    434 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 :
    435 \begin{lstlisting}
    436 monitor global;
    437 
    438 extern void doStuff(); //uses global
    439 
    440 void foo(monitor & mutex m) {
    441         //...
    442         doStuff(); //warning can release monitor m
    443         //...
    444 }
    445 
    446 foo(global);
    447 \end{lstlisting}
    448 
    449 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 :
    450 \begin{lstlisting}
    451 struct condition { /*...*/ };
    452 
    453 // Second argument is a variable length tuple.
    454 void wait(condition & cond, [...] monitorsToRelease);
    455 void signal(condition & cond);
    456 
    457 struct conditionN { /*...*/ };
    458 
    459 void ?{}(conditionN* this, /*list of N monitors to release*/);
    460 void wait(conditionN & cond);
    461 void signal(conditionN & cond);
    462 \end{lstlisting}
    463 
    464 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.
    465 
    466 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.
    467 \\
    468 
     457% ####### #     # #######         #####   #####  #     # ####### ######
     458% #        #   #     #           #     # #     # #     # #       #     #
     459% #         # #      #           #       #       #     # #       #     #
     460% #####      #       #            #####  #       ####### #####   #     #
     461% #         # #      #    ###          # #       #     # #       #     #
     462% #        #   #     #    ###    #     # #     # #     # #       #     #
     463% ####### #     #    #    ###     #####   #####  #     # ####### ######
     464\newpage
    469465\subsection{External scheduling} \label{extsched}
    470466As 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.
    … …  
    496492In 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.
    497493\\
     494
     495% #       ####### #######  #####  #######    ####### ######        #  #####
     496% #       #     # #     # #     # #          #     # #     #       # #     #
     497% #       #     # #     # #       #          #     # #     #       # #
     498% #       #     # #     #  #####  #####      #     # ######        #  #####
     499% #       #     # #     #       # #          #     # #     # #     #       #
     500% #       #     # #     # #     # #          #     # #     # #     # #     #
     501% ####### ####### #######  #####  #######    ####### ######   #####   #####
    498502
    499503\subsubsection{Loose object definitions}
    … …  
    587591An 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.
    588592
     593% #     # #     # #       ####### ###    #     # ####### #     #
     594% ##   ## #     # #          #     #     ##   ## #     # ##    #
     595% # # # # #     # #          #     #     # # # # #     # # #   #
     596% #  #  # #     # #          #     #     #  #  # #     # #  #  #
     597% #     # #     # #          #     #     #     # #     # #   # #
     598% #     # #     # #          #     #     #     # #     # #    ##
     599% #     #  #####  #######    #    ###    #     # ####### #     #
     600
    589601\subsubsection{Multi-monitor scheduling}
    590602
    … …  
    629641Note 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.
    630642
     643% ######  ####### #######    #    ### #        #####
     644% #     # #          #      # #    #  #       #     #
     645% #     # #          #     #   #   #  #       #
     646% #     # #####      #    #     #  #  #        #####
     647% #     # #          #    #######  #  #             #
     648% #     # #          #    #     #  #  #       #     #
     649% ######  #######    #    #     # ### #######  #####
     650%
     651%                #####  #     # ####### #     # #######  #####
     652%             #     # #     # #       #     # #       #     #
     653%             #     # #     # #       #     # #       #
     654%    #####    #     # #     # #####   #     # #####    #####
     655%             #   # # #     # #       #     # #             #
     656%             #    #  #     # #       #     # #       #     #
     657%                #### #  #####  #######  #####  #######  #####
     658
     659
    631660\subsubsection{Implementation Details: External scheduling queues}
    632661To 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.
    … …  
    636665
    637666\newpage
     667% ######     #    ######     #    #       #       ####### #       ###  #####  #     #
     668% #     #   # #   #     #   # #   #       #       #       #        #  #     # ##   ##
     669% #     #  #   #  #     #  #   #  #       #       #       #        #  #       # # # #
     670% ######  #     # ######  #     # #       #       #####   #        #   #####  #  #  #
     671% #       ####### #   #   ####### #       #       #       #        #        # #     #
     672% #       #     # #    #  #     # #       #       #       #        #  #     # #     #
     673% #       #     # #     # #     # ####### ####### ####### ####### ###  #####  #     #
    638674\section{Parallelism}
    639 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.
     675Historically, 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.
    640676
    641677\subsection{User-level threads}
    642678A 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.
    643679
    644 Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}.
     680Examples of languages that support are Java~\cite{Java}, Haskell~\cite{Haskell} and \uC~\cite{uC++book}.
    645681
    646682\subsection{Jobs and thread pools}
    647683The 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.
    648 The golden standard of this implementation is Intel's TBB library\cite{TBB}.
     684The golden standard of this implementation is Intel's TBB library~\cite{TBB}.
    649685
    650686\subsection{Fibers : user-level threads without preemption}
    651687Finally, 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.
    652 An example of a language that uses fibers is Go\cite{Go}
     688An example of a language that uses fibers is Go~\cite{Go}
    653689
    654690\subsection{Paradigm performance}
    655691While 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.
     692
     693%  #####  #######    #          ####### ######  ######
     694% #     # #         # #            #    #     # #     #
     695% #       #        #   #           #    #     # #     #
     696% #       #####   #     # #####    #    ######  ######
     697% #       #       #######          #    #     # #     #
     698% #     # #       #     #          #    #     # #     #
     699%  #####  #       #     #          #    ######  ######
    656700
    657701\section{\CFA 's Thread Building Blocks}
    … …  
    673717As shown in section \ref{cfaparadigms} these different blocks being available in \CFA it is trivial to reproduce any of these paradigm.
    674718
     719% ####### #     # ######  #######    #    ######   #####
     720%    #    #     # #     # #         # #   #     # #     #
     721%    #    #     # #     # #        #   #  #     # #
     722%    #    ####### ######  #####   #     # #     #  #####
     723%    #    #     # #   #   #       ####### #     #       #
     724%    #    #     # #    #  #       #     # #     # #     #
     725%    #    #     # #     # ####### #     # ######   #####
     726
    675727\subsection{Thread Interface}
    676728The 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 :
    … …  
    680732\end{lstlisting}
    681733
    682 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 :
     734Obviously, 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 :
    683735\begin{lstlisting}
    684736        thread struct foo {};
    … …  
    843895% \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
    844896
     897%    #    #       #
     898%   # #   #       #
     899%  #   #  #       #
     900% #     # #       #
     901% ####### #       #
     902% #     # #       #
     903% #     # ####### #######
    845904\section{Putting it all together}
    846905
     906
     907
     908
     909
     910
     911
     912
     913
     914
     915% ####### #     # ####### #     # ######  #######
     916% #       #     #    #    #     # #     # #
     917% #       #     #    #    #     # #     # #
     918% #####   #     #    #    #     # ######  #####
     919% #       #     #    #    #     # #   #   #
     920% #       #     #    #    #     # #    #  #
     921% #        #####     #     #####  #     # ######
    847922\section{Future work}
    848923Concurrency 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.
    849924\subsection{Transactions}
    850925
     926% ####### #     # ######
     927% #       ##    # #     #
     928% #       # #   # #     #
     929% #####   #  #  # #     #
     930% #       #   # # #     #
     931% #       #    ## #     #
     932% ####### #     # ######
    851933\section*{Acknowledgements}
    852934
    … …  
    857939\clearpage
    858940\bibliographystyle{plain}
    859 \bibliography{pl,local}
     941\bibliography{cw92,distSharedMem,lfp92,mlw92,parallel,parallelIO,partheory,pl,pldi92,ps,realtime,techreportsPAB,visual,local}
    860942
    861943

  • doc/proposals/concurrency/glossary.tex

    r141b786 rb726084  
    11\makeglossaries
     2
     3\longnewglossaryentry{callsite-locking}
     4{name={callsite-locking}}
     5{
     6Locking done by the calling routine. With this technique, a routine calling a monitor routine will aquire the monitor \emph{before} making the call to the actuall routine.
     7}
     8
     9\longnewglossaryentry{entry-point-locking}
     10{name={entry-point-locking}}
     11{
     12Locking done by the called routine. With this technique, a monitor routine called by another routine will aquire the monitor \emph{after} entering the routine body but prior to any other code.
     13}
     14
     15\longnewglossaryentry{group-acquire}
     16{name={grouped acquiring}}
     17{
     18Implicitly acquiring several monitors when entering a monitor.
     19}
     20
     21
    222\longnewglossaryentry{uthread}
    323{name={user-level thread}}

  • doc/proposals/concurrency/version

    r141b786 rb726084  
    1 0.4.95
     10.5.146

  • src/ControlStruct/LabelFixer.h

    r141b786 rb726084  
    2626namespace ControlStruct {
    2727        /// normalizes label definitions and generates multi-level exit labels
    28         class LabelFixer : public Visitor {
     28        class LabelFixer final : public Visitor {
    2929                typedef Visitor Parent;
    3030          public:
    … …  
    3333                std::map < Label, Statement * > *resolveJumps() throw ( SemanticError );
    3434
     35                using Visitor::visit;
     36
    3537                // Declarations
    36                 virtual void visit( FunctionDecl *functionDecl );
     38                virtual void visit( FunctionDecl *functionDecl ) override;
    3739
    3840                // Statements
    3941                void visit( Statement *stmt );
    4042
    41                 virtual void visit( CompoundStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    42                 virtual void visit( NullStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    43                 virtual void visit( ExprStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    44                 virtual void visit( IfStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    45                 virtual void visit( WhileStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    46                 virtual void visit( ForStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    47                 virtual void visit( SwitchStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    48                 virtual void visit( CaseStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    49                 virtual void visit( ReturnStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    50                 virtual void visit( TryStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    51                 virtual void visit( CatchStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    52                 virtual void visit( DeclStmt *stmt ) { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
    53                 virtual void visit( BranchStmt *branchStmt );
    54                 virtual void visit( UntypedExpr *untyped );
     43                virtual void visit( CompoundStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     44                virtual void visit( NullStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     45                virtual void visit( ExprStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     46                virtual void visit( IfStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     47                virtual void visit( WhileStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     48                virtual void visit( ForStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     49                virtual void visit( SwitchStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     50                virtual void visit( CaseStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     51                virtual void visit( ReturnStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     52                virtual void visit( TryStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     53                virtual void visit( CatchStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     54                virtual void visit( DeclStmt *stmt ) override { visit( (Statement *)stmt ); return Parent::visit( stmt ); }
     55                virtual void visit( BranchStmt *branchStmt ) override;
     56                virtual void visit( UntypedExpr *untyped ) override;
    5557
    5658                Label setLabelsDef( std::list< Label > &, Statement *definition );

  • src/GenPoly/Box.cc

    r141b786 rb726084  
    6464
    6565                /// Adds layout-generation functions to polymorphic types
    66                 class LayoutFunctionBuilder : public DeclMutator {
     66                class LayoutFunctionBuilder final : public DeclMutator {
    6767                        unsigned int functionNesting;  // current level of nested functions
    6868                public:
    6969                        LayoutFunctionBuilder() : functionNesting( 0 ) {}
    7070
    71                         virtual DeclarationWithType *mutate( FunctionDecl *functionDecl );
    72                         virtual Declaration *mutate( StructDecl *structDecl );
    73                         virtual Declaration *mutate( UnionDecl *unionDecl );
     71                        using DeclMutator::mutate;
     72                        virtual DeclarationWithType *mutate( FunctionDecl *functionDecl ) override;
     73                        virtual Declaration *mutate( StructDecl *structDecl ) override;
     74                        virtual Declaration *mutate( UnionDecl *unionDecl ) override;
    7475                };
    7576
    7677                /// Replaces polymorphic return types with out-parameters, replaces calls to polymorphic functions with adapter calls as needed, and adds appropriate type variables to the function call
    77                 class Pass1 : public PolyMutator {
     78                class Pass1 final : public PolyMutator {
    7879                  public:
    7980                        Pass1();
    80                         virtual Expression *mutate( ApplicationExpr *appExpr );
    81                         virtual Expression *mutate( AddressExpr *addrExpr );
    82                         virtual Expression *mutate( UntypedExpr *expr );
    83                         virtual DeclarationWithType* mutate( FunctionDecl *functionDecl );
    84                         virtual TypeDecl *mutate( TypeDecl *typeDecl );
    85                         virtual Expression *mutate( CommaExpr *commaExpr );
    86                         virtual Expression *mutate( ConditionalExpr *condExpr );
    87                         virtual Statement * mutate( ReturnStmt *returnStmt );
    88                         virtual Type *mutate( PointerType *pointerType );
    89                         virtual Type * mutate( FunctionType *functionType );
    90 
    91                         virtual void doBeginScope();
    92                         virtual void doEndScope();
     81
     82                        using PolyMutator::mutate;
     83                        virtual Expression *mutate( ApplicationExpr *appExpr ) override;
     84                        virtual Expression *mutate( AddressExpr *addrExpr ) override;
     85                        virtual Expression *mutate( UntypedExpr *expr ) override;
     86                        virtual DeclarationWithType* mutate( FunctionDecl *functionDecl ) override;
     87                        virtual TypeDecl *mutate( TypeDecl *typeDecl ) override;
     88                        virtual Expression *mutate( CommaExpr *commaExpr ) override;
     89                        virtual Expression *mutate( ConditionalExpr *condExpr ) override;
     90                        virtual Statement * mutate( ReturnStmt *returnStmt ) override;
     91                        virtual Type *mutate( PointerType *pointerType ) override;
     92                        virtual Type * mutate( FunctionType *functionType ) override;
     93
     94                        virtual void doBeginScope() override;
     95                        virtual void doEndScope() override;
    9396                  private:
    9497                        /// Pass the extra type parameters from polymorphic generic arguments or return types into a function application
    … …  
    135138                /// * Moves polymorphic returns in function types to pointer-type parameters
    136139                /// * adds type size and assertion parameters to parameter lists
    137                 class Pass2 : public PolyMutator {
     140                class Pass2 final : public PolyMutator {
    138141                  public:
    139142                        template< typename DeclClass >
    140143                        DeclClass *handleDecl( DeclClass *decl, Type *type );
    141                         virtual DeclarationWithType *mutate( FunctionDecl *functionDecl );
    142                         virtual ObjectDecl *mutate( ObjectDecl *objectDecl );
    143                         virtual TypeDecl *mutate( TypeDecl *typeDecl );
    144                         virtual TypedefDecl *mutate( TypedefDecl *typedefDecl );
    145                         virtual Type *mutate( PointerType *pointerType );
    146                         virtual Type *mutate( FunctionType *funcType );
     144
     145                        using PolyMutator::mutate;
     146                        virtual DeclarationWithType *mutate( FunctionDecl *functionDecl ) override;
     147                        virtual ObjectDecl *mutate( ObjectDecl *objectDecl ) override;
     148                        virtual TypeDecl *mutate( TypeDecl *typeDecl ) override;
     149                        virtual TypedefDecl *mutate( TypedefDecl *typedefDecl ) override;
     150                        virtual Type *mutate( PointerType *pointerType ) override;
     151                        virtual Type *mutate( FunctionType *funcType ) override;
    147152
    148153                  private:
    … …  
    156161                /// * Calculates polymorphic offsetof expressions from offset array
    157162                /// * Inserts dynamic calculation of polymorphic type layouts where needed
    158                 class PolyGenericCalculator : public PolyMutator {
     163                class PolyGenericCalculator final : public PolyMutator {
    159164                public:
    160165                        typedef PolyMutator Parent;
    … …  
    163168                        template< typename DeclClass >
    164169                        DeclClass *handleDecl( DeclClass *decl, Type *type );
    165                         virtual DeclarationWithType *mutate( FunctionDecl *functionDecl );
    166                         virtual ObjectDecl *mutate( ObjectDecl *objectDecl );
    167                         virtual TypedefDecl *mutate( TypedefDecl *objectDecl );
    168                         virtual TypeDecl *mutate( TypeDecl *objectDecl );
    169                         virtual Statement *mutate( DeclStmt *declStmt );
    170                         virtual Type *mutate( PointerType *pointerType );
    171                         virtual Type *mutate( FunctionType *funcType );
    172                         virtual Expression *mutate( MemberExpr *memberExpr );
    173                         virtual Expression *mutate( SizeofExpr *sizeofExpr );
    174                         virtual Expression *mutate( AlignofExpr *alignofExpr );
    175                         virtual Expression *mutate( OffsetofExpr *offsetofExpr );
    176                         virtual Expression *mutate( OffsetPackExpr *offsetPackExpr );
    177 
    178                         virtual void doBeginScope();
    179                         virtual void doEndScope();
     170                        virtual DeclarationWithType *mutate( FunctionDecl *functionDecl ) override;
     171                        virtual ObjectDecl *mutate( ObjectDecl *objectDecl ) override;
     172                        virtual TypedefDecl *mutate( TypedefDecl *objectDecl ) override;
     173                        virtual TypeDecl *mutate( TypeDecl *objectDecl ) override;
     174                        virtual Statement *mutate( DeclStmt *declStmt ) override;
     175                        virtual Type *mutate( PointerType *pointerType ) override;
     176                        virtual Type *mutate( FunctionType *funcType ) override;
     177                        virtual Expression *mutate( MemberExpr *memberExpr ) override;
     178                        virtual Expression *mutate( SizeofExpr *sizeofExpr ) override;
     179                        virtual Expression *mutate( AlignofExpr *alignofExpr ) override;
     180                        virtual Expression *mutate( OffsetofExpr *offsetofExpr ) override;
     181                        virtual Expression *mutate( OffsetPackExpr *offsetPackExpr ) override;
     182
     183                        virtual void doBeginScope() override;
     184                        virtual void doEndScope() override;
    180185
    181186                private:
    … …  
    197202
    198203                /// Replaces initialization of polymorphic values with alloca, declaration of dtype/ftype with appropriate void expression, and sizeof expressions of polymorphic types with the proper variable
    199                 class Pass3 : public PolyMutator {
     204                class Pass3 final : public PolyMutator {
    200205                  public:
    201206                        template< typename DeclClass >
    202207                        DeclClass *handleDecl( DeclClass *decl, Type *type );
    203                         virtual DeclarationWithType *mutate( FunctionDecl *functionDecl );
    204                         virtual ObjectDecl *mutate( ObjectDecl *objectDecl );
    205                         virtual TypedefDecl *mutate( TypedefDecl *objectDecl );
    206                         virtual TypeDecl *mutate( TypeDecl *objectDecl );
    207                         virtual Type *mutate( PointerType *pointerType );
    208                         virtual Type *mutate( FunctionType *funcType );
     208
     209                        using PolyMutator::mutate;
     210                        virtual DeclarationWithType *mutate( FunctionDecl *functionDecl ) override;
     211                        virtual ObjectDecl *mutate( ObjectDecl *objectDecl ) override;
     212                        virtual TypedefDecl *mutate( TypedefDecl *objectDecl ) override;
     213                        virtual TypeDecl *mutate( TypeDecl *objectDecl ) override;
     214                        virtual Type *mutate( PointerType *pointerType ) override;
     215                        virtual Type *mutate( FunctionType *funcType ) override;
    209216                  private:
    210217                };

  • src/GenPoly/InstantiateGeneric.cc

    r141b786 rb726084  
    147147
    148148        /// Mutator pass that replaces concrete instantiations of generic types with actual struct declarations, scoped appropriately
    149         class GenericInstantiator : public DeclMutator {
     149        class GenericInstantiator final : public DeclMutator {
    150150                /// Map of (generic type, parameter list) pairs to concrete type instantiations
    151151                InstantiationMap< AggregateDecl, AggregateDecl > instantiations;
    … …  
    158158                GenericInstantiator() : DeclMutator(), instantiations(), dtypeStatics(), typeNamer("_conc_") {}
    159159
    160                 virtual Type* mutate( StructInstType *inst );
    161                 virtual Type* mutate( UnionInstType *inst );
    162 
    163                 virtual void doBeginScope();
    164                 virtual void doEndScope();
     160                using DeclMutator::mutate;
     161                virtual Type* mutate( StructInstType *inst ) override;
     162                virtual Type* mutate( UnionInstType *inst ) override;
     163
     164                virtual void doBeginScope() override;
     165                virtual void doEndScope() override;
    165166        private:
    166167                /// Wrap instantiation lookup for structs

  • src/GenPoly/Specialize.cc

    r141b786 rb726084  
    3636        const std::list<Label> noLabels;
    3737
    38         class Specialize : public PolyMutator {
     38        class Specialize final : public PolyMutator {
    3939          public:
    4040                Specialize( std::string paramPrefix = "_p" );
    4141
    42                 virtual Expression * mutate( ApplicationExpr *applicationExpr );
    43                 virtual Expression * mutate( AddressExpr *castExpr );
    44                 virtual Expression * mutate( CastExpr *castExpr );
     42                using PolyMutator::mutate;
     43                virtual Expression * mutate( ApplicationExpr *applicationExpr ) override;
     44                virtual Expression * mutate( AddressExpr *castExpr ) override;
     45                virtual Expression * mutate( CastExpr *castExpr ) override;
    4546                // virtual Expression * mutate( LogicalExpr *logicalExpr );
    4647                // virtual Expression * mutate( ConditionalExpr *conditionalExpr );

  • src/InitTweak/FixInit.cc

    r141b786 rb726084  
    4949namespace InitTweak {
    5050        namespace {
    51                 class InsertImplicitCalls : public GenPoly::PolyMutator {
     51                class InsertImplicitCalls final : public GenPoly::PolyMutator {
    5252                public:
    5353                        /// wrap function application expressions as ImplicitCopyCtorExpr nodes so that it is easy to identify which
    … …  
    5555                        static void insert( std::list< Declaration * > & translationUnit );
    5656
    57                         virtual Expression * mutate( ApplicationExpr * appExpr );
     57                        using GenPoly::PolyMutator::mutate;
     58                        virtual Expression * mutate( ApplicationExpr * appExpr ) override;
    5859                };
    5960
    60                 class ResolveCopyCtors : public SymTab::Indexer {
     61                class ResolveCopyCtors final : public SymTab::Indexer {
    6162                public:
    6263                        /// generate temporary ObjectDecls for each argument and return value of each ImplicitCopyCtorExpr,
    … …  
    6869                        using Parent::visit;
    6970
    70                         virtual void visit( ImplicitCopyCtorExpr * impCpCtorExpr );
     71                        virtual void visit( ImplicitCopyCtorExpr * impCpCtorExpr ) override;
    7172                        virtual void visit( UniqueExpr * unqExpr );
    7273
    … …  
    8889                        using Parent::visit;
    8990                        typedef std::set< ObjectDecl * > ObjectSet;
    90                         virtual void visit( CompoundStmt *compoundStmt );
    91                         virtual void visit( DeclStmt *stmt );
     91                        virtual void visit( CompoundStmt *compoundStmt ) override;
     92                        virtual void visit( DeclStmt *stmt ) override;
    9293                  protected:
    9394                        ObjectSet curVars;
    … …  
    109110                }
    110111
    111                 class LabelFinder : public ObjDeclCollector {
     112                class LabelFinder final : public ObjDeclCollector {
    112113                  public:
    113114                        typedef ObjDeclCollector Parent;
    … …  
    123124                        // subclasses are added, there is only one place that the code has to be updated, rather than ensure that
    124125                        // every specialized class knows about every new kind of statement that might be added.
    125                         virtual void visit( CompoundStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    126                         virtual void visit( ExprStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    127                         virtual void visit( AsmStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    128                         virtual void visit( IfStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    129                         virtual void visit( WhileStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    130                         virtual void visit( ForStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    131                         virtual void visit( SwitchStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    132                         virtual void visit( CaseStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    133                         virtual void visit( BranchStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    134                         virtual void visit( ReturnStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    135                         virtual void visit( TryStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    136                         virtual void visit( CatchStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    137                         virtual void visit( FinallyStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    138                         virtual void visit( NullStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    139                         virtual void visit( DeclStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
    140                         virtual void visit( ImplicitCtorDtorStmt *stmt ) { handleStmt( stmt ); return Parent::visit( stmt ); }
     126                        using Parent::visit;
     127                        virtual void visit( CompoundStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     128                        virtual void visit( ExprStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     129                        virtual void visit( AsmStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     130                        virtual void visit( IfStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     131                        virtual void visit( WhileStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     132                        virtual void visit( ForStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     133                        virtual void visit( SwitchStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     134                        virtual void visit( CaseStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     135                        virtual void visit( BranchStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     136                        virtual void visit( ReturnStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     137                        virtual void visit( TryStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     138                        virtual void visit( CatchStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     139                        virtual void visit( FinallyStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     140                        virtual void visit( NullStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     141                        virtual void visit( DeclStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
     142                        virtual void visit( ImplicitCtorDtorStmt *stmt ) override { handleStmt( stmt ); return Parent::visit( stmt ); }
    141143                };
    142144
    143                 class InsertDtors : public ObjDeclCollector {
     145                class InsertDtors final : public ObjDeclCollector {
    144146                public:
    145147                        /// insert destructor calls at the appropriate places.  must happen before CtorInit nodes are removed
    … …  
    153155                        InsertDtors( LabelFinder & finder ) : labelVars( finder.vars ) {}
    154156
    155                         virtual void visit( ObjectDecl * objDecl );
    156 
    157                         virtual void visit( CompoundStmt * compoundStmt );
    158                         virtual void visit( ReturnStmt * returnStmt );
    159                         virtual void visit( BranchStmt * stmt );
     157                        using Parent::visit;
     158
     159                        virtual void visit( ObjectDecl * objDecl ) override;
     160
     161                        virtual void visit( CompoundStmt * compoundStmt ) override;
     162                        virtual void visit( ReturnStmt * returnStmt ) override;
     163                        virtual void visit( BranchStmt * stmt ) override;
    160164                private:
    161165                        void handleGoto( BranchStmt * stmt );
    … …  
    165169                };
    166170
    167                 class FixInit : public GenPoly::PolyMutator {
     171                class FixInit final : public GenPoly::PolyMutator {
    168172                  public:
    169173                        /// expand each object declaration to use its constructor after it is declared.
    170174                        static void fixInitializers( std::list< Declaration * > &translationUnit );
    171175
    172                         virtual DeclarationWithType * mutate( ObjectDecl *objDecl );
     176                        using GenPoly::PolyMutator::mutate;
     177                        virtual DeclarationWithType * mutate( ObjectDecl *objDecl ) override;
    173178
    174179                        std::list< Declaration * > staticDtorDecls;
    175180                };
    176181
    177                 class FixCopyCtors : public GenPoly::PolyMutator {
     182                class FixCopyCtors final : public GenPoly::PolyMutator {
    178183                  public:
    179184                        /// expand ImplicitCopyCtorExpr nodes into the temporary declarations, copy constructors, call expression,
    … …  
    181186                        static void fixCopyCtors( std::list< Declaration * > &translationUnit );
    182187
    183                         virtual Expression * mutate( ImplicitCopyCtorExpr * impCpCtorExpr );
    184                         virtual Expression * mutate( UniqueExpr * unqExpr );
     188                        using GenPoly::PolyMutator::mutate;
     189                        virtual Expression * mutate( ImplicitCopyCtorExpr * impCpCtorExpr ) override;
     190                        virtual Expression * mutate( UniqueExpr * unqExpr ) override;
    185191                };
    186192
    187                 class GenStructMemberCalls : public SymTab::Indexer {
     193                class GenStructMemberCalls final : public SymTab::Indexer {
    188194                  public:
    189195                        typedef Indexer Parent;
    … …  
    193199                        static void generate( std::list< Declaration * > & translationUnit );
    194200
    195                         virtual void visit( FunctionDecl * funcDecl );
    196 
    197                         virtual void visit( MemberExpr * memberExpr );
    198                         virtual void visit( ApplicationExpr * appExpr );
     201                        using Parent::visit;
     202
     203                        virtual void visit( FunctionDecl * funcDecl ) override;
     204
     205                        virtual void visit( MemberExpr * memberExpr ) override;
     206                        virtual void visit( ApplicationExpr * appExpr ) override;
    199207
    200208                        SemanticError errors;
    … …  
    214222                // resolve UntypedExprs that are found within newly
    215223                // generated constructor/destructor calls
    216                 class MutatingResolver : public Mutator {
     224                class MutatingResolver final : public Mutator {
    217225                  public:
    218226                        MutatingResolver( SymTab::Indexer & indexer ) : indexer( indexer ) {}
    219227
    220                         virtual DeclarationWithType* mutate( ObjectDecl *objectDecl );
    221 
    222                         virtual Expression* mutate( UntypedExpr *untypedExpr );
    223                         private:
     228                        using Mutator::mutate;
     229                        virtual DeclarationWithType* mutate( ObjectDecl *objectDecl ) override;
     230                        virtual Expression* mutate( UntypedExpr *untypedExpr ) override;
     231
     232                  private:
    224233                        SymTab::Indexer & indexer;
    225234                };
    226235
    227                 class FixCtorExprs : public GenPoly::DeclMutator {
     236                class FixCtorExprs final : public GenPoly::DeclMutator {
    228237                  public:
    229238                        /// expands ConstructorExpr nodes into comma expressions, using a temporary for the first argument
    230239                        static void fix( std::list< Declaration * > & translationUnit );
    231240
    232                         virtual Expression * mutate( ConstructorExpr * ctorExpr );
     241                        using GenPoly::DeclMutator::mutate;
     242                        virtual Expression * mutate( ConstructorExpr * ctorExpr ) override;
    233243                };
    234244        } // namespace

  • src/InitTweak/GenInit.cc

    r141b786 rb726084  
    3737        }
    3838
    39         class ReturnFixer : public GenPoly::PolyMutator {
     39        class ReturnFixer final : public GenPoly::PolyMutator {
    4040          public:
    4141                /// consistently allocates a temporary variable for the return value
    … …  
    4646                ReturnFixer();
    4747
    48                 virtual DeclarationWithType * mutate( FunctionDecl *functionDecl );
    49 
    50                 virtual Statement * mutate( ReturnStmt * returnStmt );
     48                using GenPoly::PolyMutator::mutate;
     49                virtual DeclarationWithType * mutate( FunctionDecl *functionDecl ) override;
     50                virtual Statement * mutate( ReturnStmt * returnStmt ) override;
    5151
    5252          protected:
    … …  
    5656        };
    5757
    58         class CtorDtor : public GenPoly::PolyMutator {
     58        class CtorDtor final : public GenPoly::PolyMutator {
    5959          public:
    6060                typedef GenPoly::PolyMutator Parent;
    … …  
    6666                static void generateCtorDtor( std::list< Declaration * > &translationUnit );
    6767
    68                 virtual DeclarationWithType * mutate( ObjectDecl * );
    69                 virtual DeclarationWithType * mutate( FunctionDecl *functionDecl );
     68                virtual DeclarationWithType * mutate( ObjectDecl * ) override;
     69                virtual DeclarationWithType * mutate( FunctionDecl *functionDecl ) override;
    7070                // should not traverse into any of these declarations to find objects
    7171                // that need to be constructed or destructed
    72                 virtual Declaration* mutate( StructDecl *aggregateDecl );
    73                 virtual Declaration* mutate( UnionDecl *aggregateDecl ) { return aggregateDecl; }
    74                 virtual Declaration* mutate( EnumDecl *aggregateDecl ) { return aggregateDecl; }
    75                 virtual Declaration* mutate( TraitDecl *aggregateDecl ) { return aggregateDecl; }
    76                 virtual TypeDecl* mutate( TypeDecl *typeDecl ) { return typeDecl; }
    77                 virtual Declaration* mutate( TypedefDecl *typeDecl ) { return typeDecl; }
    78 
    79                 virtual Type * mutate( FunctionType *funcType ) { return funcType; }
    80 
    81                 virtual CompoundStmt * mutate( CompoundStmt * compoundStmt );
     72                virtual Declaration* mutate( StructDecl *aggregateDecl ) override;
     73                virtual Declaration* mutate( UnionDecl *aggregateDecl ) override { return aggregateDecl; }
     74                virtual Declaration* mutate( EnumDecl *aggregateDecl ) override { return aggregateDecl; }
     75                virtual Declaration* mutate( TraitDecl *aggregateDecl ) override { return aggregateDecl; }
     76                virtual TypeDecl* mutate( TypeDecl *typeDecl ) override { return typeDecl; }
     77                virtual Declaration* mutate( TypedefDecl *typeDecl ) override { return typeDecl; }
     78
     79                virtual Type * mutate( FunctionType *funcType ) override { return funcType; }
     80
     81                virtual CompoundStmt * mutate( CompoundStmt * compoundStmt ) override;
    8282
    8383          private:
    … …  
    9393        };
    9494
    95         class HoistArrayDimension : public GenPoly::DeclMutator {
     95        class HoistArrayDimension final : public GenPoly::DeclMutator {
    9696          public:
    9797                typedef GenPoly::DeclMutator Parent;
    … …  
    103103
    104104          private:
    105                 virtual DeclarationWithType * mutate( ObjectDecl * objectDecl );
    106                 virtual DeclarationWithType * mutate( FunctionDecl *functionDecl );
     105                using Parent::mutate;
     106
     107                virtual DeclarationWithType * mutate( ObjectDecl * objectDecl ) override;
     108                virtual DeclarationWithType * mutate( FunctionDecl *functionDecl ) override;
    107109                // should not traverse into any of these declarations to find objects
    108110                // that need to be constructed or destructed
    109                 virtual Declaration* mutate( StructDecl *aggregateDecl ) { return aggregateDecl; }
    110                 virtual Declaration* mutate( UnionDecl *aggregateDecl ) { return aggregateDecl; }
    111                 virtual Declaration* mutate( EnumDecl *aggregateDecl ) { return aggregateDecl; }
    112                 virtual Declaration* mutate( TraitDecl *aggregateDecl ) { return aggregateDecl; }
    113                 virtual TypeDecl* mutate( TypeDecl *typeDecl ) { return typeDecl; }
    114                 virtual Declaration* mutate( TypedefDecl *typeDecl ) { return typeDecl; }
    115 
    116                 virtual Type* mutate( FunctionType *funcType ) { return funcType; }
     111                virtual Declaration* mutate( StructDecl *aggregateDecl ) override { return aggregateDecl; }
     112                virtual Declaration* mutate( UnionDecl *aggregateDecl ) override { return aggregateDecl; }
     113                virtual Declaration* mutate( EnumDecl *aggregateDecl ) override { return aggregateDecl; }
     114                virtual Declaration* mutate( TraitDecl *aggregateDecl ) override { return aggregateDecl; }
     115                virtual TypeDecl* mutate( TypeDecl *typeDecl ) override { return typeDecl; }
     116                virtual Declaration* mutate( TypedefDecl *typeDecl ) override { return typeDecl; }
     117
     118                virtual Type* mutate( FunctionType *funcType ) override { return funcType; }
    117119
    118120                void hoist( Type * type );

  • src/InitTweak/InitTweak.h

    r141b786 rb726084  
    100100
    101101                class ExpanderImpl;
     102                typedef std::list< Expression * > IndexList;
    102103        private:
    103104                std::shared_ptr< ExpanderImpl > expander;
    … …  
    105106
    106107                // invariant: list of size 2N (elements come in pairs [index, dimension])
    107                 typedef std::list< Expression * > IndexList;
    108108                IndexList indices;
    109109        };

  • src/Makefile.am

    r141b786 rb726084  
    66## file "LICENCE" distributed with Cforall.
    77##
    8 ## Makefile.am -- 
     8## Makefile.am --
    99##
    1010## Author           : Peter A. Buhr
    1111## Created On       : Sun May 31 08:51:46 2015
    1212## Last Modified By : Peter A. Buhr
    13 ## Last Modified On : Sat Sep 24 15:03:52 2016
    14 ## Update Count     : 73
     13## Last Modified On : Thu Oct 27 20:41:25 2016
     14## Update Count     : 75
    1515###############################################################################
    1616
    … …  
    4141driver_cfa_cpp_SOURCES = ${SRC}
    4242driver_cfa_cpp_LDADD = ${LEXLIB} -ldl                   # yywrap
    43 driver_cfa_cpp_CXXFLAGS = -Wno-deprecated -Wall -DDEBUG_ALL -rdynamic -I${abs_top_srcdir}/src/include
     43driver_cfa_cpp_CXXFLAGS = -Wno-deprecated -Wall -DDEBUG_ALL -I${abs_top_srcdir}/src/include -DYY_NO_INPUT
     44driver_cfa_cpp_LDFLAGS = -Xlinker -export-dynamic
    4445
    4546MAINTAINERCLEANFILES += ${libdir}/${notdir ${cfa_cpplib_PROGRAMS}}

  • src/Makefile.in

    r141b786 rb726084  
    198198driver_cfa_cpp_DEPENDENCIES = $(am__DEPENDENCIES_1)
    199199driver_cfa_cpp_LINK = $(CXXLD) $(driver_cfa_cpp_CXXFLAGS) $(CXXFLAGS) \
    200         $(AM_LDFLAGS) $(LDFLAGS) -o $@
     200        $(driver_cfa_cpp_LDFLAGS) $(LDFLAGS) -o $@
    201201DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir)
    202202depcomp = $(SHELL) $(top_srcdir)/automake/depcomp
    … …  
    267267CFA_PREFIX = @CFA_PREFIX@
    268268CFLAGS = @CFLAGS@
    269 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    270269CPP = @CPP@
    271270CPPFLAGS = @CPPFLAGS@
    … …  
    419418driver_cfa_cpp_SOURCES = ${SRC}
    420419driver_cfa_cpp_LDADD = ${LEXLIB} -ldl                   # yywrap
    421 driver_cfa_cpp_CXXFLAGS = -Wno-deprecated -Wall -DDEBUG_ALL -rdynamic -I${abs_top_srcdir}/src/include
     420driver_cfa_cpp_CXXFLAGS = -Wno-deprecated -Wall -DDEBUG_ALL -I${abs_top_srcdir}/src/include -DYY_NO_INPUT
     421driver_cfa_cpp_LDFLAGS = -Xlinker -export-dynamic
    422422all: $(BUILT_SOURCES)
    423423        $(MAKE) $(AM_MAKEFLAGS) all-am

  • src/Parser/ParseNode.h

    r141b786 rb726084  
    109109        ExpressionNode * set_extension( bool exten ) { extension = exten; return this; }
    110110
    111         void print( std::ostream &os, int indent = 0 ) const {}
     111        virtual void print( std::ostream &os, int indent = 0 ) const override {}
    112112        void printOneLine( std::ostream &os, int indent = 0 ) const {}
    113113
    … …  
    191191//##############################################################################
    192192
    193 class TypeData;
     193struct TypeData;
    194194
    195195class DeclarationNode : public ParseNode {
    … …  
    275275        }
    276276
    277         void print( std::ostream &os, int indent = 0 ) const;
    278         void printList( std::ostream &os, int indent = 0 ) const;
     277        virtual void print( std::ostream &os, int indent = 0 ) const override;
     278        virtual void printList( std::ostream &os, int indent = 0 ) const override;
    279279
    280280        Declaration * build() const;
    … …  
    349349        virtual StatementNode * append_last_case( StatementNode * );
    350350
    351         virtual void print( std::ostream &os, int indent = 0 ) {}
    352         virtual void printList( std::ostream &os, int indent = 0 ) {}
     351        virtual void print( std::ostream &os, int indent = 0 ) const override {}
     352        virtual void printList( std::ostream &os, int indent = 0 ) const override {}
    353353  private:
    354354        std::unique_ptr<Statement> stmt;

  • src/ResolvExpr/AlternativeFinder.h

    r141b786 rb726084  
    9595        Expression *resolveInVoidContext( Expression *expr, const SymTab::Indexer &indexer, TypeEnvironment &env );
    9696
    97         void resolveObject( const SymTab::Indexer & indexer, ObjectDecl * objectDecl );
    98 
    9997        template< typename InputIterator, typename OutputIterator >
    10098        void findMinCost( InputIterator begin, InputIterator end, OutputIterator out ) {

  • src/ResolvExpr/AlternativePrinter.h

    r141b786 rb726084  
    55// file "LICENCE" distributed with Cforall.
    66//
    7 // AlternativePrinter.h -- 
     7// AlternativePrinter.h --
    88//
    99// Author           : Richard C. Bilson
    … …  
    2323
    2424namespace ResolvExpr {
    25         class AlternativePrinter : public SymTab::Indexer {
     25        class AlternativePrinter final : public SymTab::Indexer {
    2626          public:
    2727                AlternativePrinter( std::ostream &os );
    28                 virtual void visit( ExprStmt *exprStmt );
     28
     29                using SymTab::Indexer::visit;
     30                virtual void visit( ExprStmt *exprStmt ) override;
    2931          private:
    3032                std::ostream &os;

  • src/ResolvExpr/Resolver.cc

    r141b786 rb726084  
    3333
    3434namespace ResolvExpr {
    35         class Resolver : public SymTab::Indexer {
     35        class Resolver final : public SymTab::Indexer {
    3636          public:
    3737                Resolver() : SymTab::Indexer( false ) {}
    38                 Resolver( const SymTab::Indexer & indexer ) : SymTab::Indexer( indexer ) {}
    39 
    40                 virtual void visit( FunctionDecl *functionDecl );
    41                 virtual void visit( ObjectDecl *objectDecl );
    42                 virtual void visit( TypeDecl *typeDecl );
    43                 virtual void visit( EnumDecl * enumDecl );
    44 
    45                 virtual void visit( ArrayType * at );
    46                 virtual void visit( PointerType * at );
    47 
    48                 virtual void visit( ExprStmt *exprStmt );
    49                 virtual void visit( AsmExpr *asmExpr );
    50                 virtual void visit( AsmStmt *asmStmt );
    51                 virtual void visit( IfStmt *ifStmt );
    52                 virtual void visit( WhileStmt *whileStmt );
    53                 virtual void visit( ForStmt *forStmt );
    54                 virtual void visit( SwitchStmt *switchStmt );
    55                 virtual void visit( CaseStmt *caseStmt );
    56                 virtual void visit( BranchStmt *branchStmt );
    57                 virtual void visit( ReturnStmt *returnStmt );
    58 
    59                 virtual void visit( SingleInit *singleInit );
    60                 virtual void visit( ListInit *listInit );
    61                 virtual void visit( ConstructorInit *ctorInit );
     38
     39                using SymTab::Indexer::visit;
     40                virtual void visit( FunctionDecl *functionDecl ) override;
     41                virtual void visit( ObjectDecl *functionDecl ) override;
     42                virtual void visit( TypeDecl *typeDecl ) override;
     43                virtual void visit( EnumDecl * enumDecl ) override;
     44
     45                virtual void visit( ArrayType * at ) override;
     46                virtual void visit( PointerType * at ) override;
     47
     48                virtual void visit( ExprStmt *exprStmt ) override;
     49                virtual void visit( AsmExpr *asmExpr ) override;
     50                virtual void visit( AsmStmt *asmStmt ) override;
     51                virtual void visit( IfStmt *ifStmt ) override;
     52                virtual void visit( WhileStmt *whileStmt ) override;
     53                virtual void visit( ForStmt *forStmt ) override;
     54                virtual void visit( SwitchStmt *switchStmt ) override;
     55                virtual void visit( CaseStmt *caseStmt ) override;
     56                virtual void visit( BranchStmt *branchStmt ) override;
     57                virtual void visit( ReturnStmt *returnStmt ) override;
     58
     59                virtual void visit( SingleInit *singleInit ) override;
     60                virtual void visit( ListInit *listInit ) override;
     61                virtual void visit( ConstructorInit *ctorInit ) override;
    6262          private:
    6363        typedef std::list< Initializer * >::iterator InitIterator;
    … …  
    6969          void resolveSingleAggrInit( Declaration *, InitIterator &, InitIterator & );
    7070          void fallbackInit( ConstructorInit * ctorInit );
     71
    7172                Type * functionReturn = nullptr;
    7273                Type *initContext = nullptr;
    … …  
    533534        }
    534535
    535         void resolveObject( const SymTab::Indexer & indexer, ObjectDecl * objectDecl ) {
    536                 Resolver resolver( indexer );
    537                 objectDecl->accept( resolver );
    538         }
    539 
    540536        void Resolver::visit( ConstructorInit *ctorInit ) {
    541537                // xxx - fallback init has been removed => remove fallbackInit function and remove complexity from FixInit and remove C-init from ConstructorInit

  • src/ResolvExpr/TypeMap.h

    r141b786 rb726084  
    3838                typedef typename std::map< std::string, Value* > ValueMap;
    3939                typedef typename ValueMap::iterator ValueMapIterator;
    40                
     40
    4141                Value *voidValue;                                     ///< Value for void type
    4242                Value *basicValue[BasicType::NUMBER_OF_BASIC_TYPES];  ///< Values for basic types
    … …  
    5454                        /// One scope of map rollbacks
    5555                        typedef std::vector< std::pair< ValueMapIterator, Value* > > MapScope;
    56                        
     56
    5757                        PointerScope pointers;  ///< Value pointers to roll back to their previous state
    5858                        MapScope mapNodes;      ///< Value map iterators to roll back to their previous state
    … …  
    6868
    6969                std::vector< Rollback > scopes;  ///< Scope rollback information
    70                
     70
    7171                struct Lookup : public Visitor {
    7272                        Lookup( TypeMap<Value> &typeMap ) : typeMap( typeMap ), found( 0 ), toInsert( 0 ) {}
    … …  
    8787                                return found;
    8888                        }
    89                        
     89
    9090                        void findAndReplace( Value *&loc ) {
    9191                                found = loc;
    … …  
    109109                                }
    110110                        }
    111                        
     111
    112112                        virtual void visit( VoidType *voidType ) {
    113113                                findAndReplace( typeMap.voidValue );
    114114                        }
    115                        
     115
    116116                        virtual void visit( BasicType *basicType ) {
    117117                                findAndReplace( typeMap.basicValue[basicType->get_kind()] );
    118118                        }
    119                        
     119
    120120                        virtual void visit( PointerType *pointerType ) {
    121121                                // NOTE This is one of the places where the apporoximation of the resolver is (deliberately) poor;
    … …  
    129129                                }
    130130                        }
    131                        
     131
    132132                        virtual void visit( ArrayType *arrayType ) {
    133133                                if ( dynamic_cast< FunctionType* >( arrayType->get_base() ) ) {
    … …  
    137137                                }
    138138                        }
    139                        
     139
    140140                        virtual void visit( FunctionType *functionType ) {
    141141                                findAndReplace( typeMap.functionPointerValue );
    142142                        }
    143                        
     143
    144144                        virtual void visit( StructInstType *structType ) {
    145145                                findAndReplace( typeMap.structValue, structType->get_name() );
    146146                        }
    147                        
     147
    148148                        virtual void visit( UnionInstType *unionType ) {
    149149                                findAndReplace( typeMap.unionValue, unionType->get_name() );
    150150                        }
    151                        
     151
    152152                        virtual void visit( EnumInstType *enumType ) {
    153153                                findAndReplace( typeMap.enumValue, enumType->get_name() );
    … …  
    157157                        Value *found;             ///< Value found (NULL if none yet)
    158158                        Value *toInsert;          ///< Value to insert (NULL if a lookup)
    159                 };  // class Lookup
    160                 friend class Lookup;
    161                
     159                };  // struct Lookup
     160                friend struct Lookup;
     161
    162162        public:
    163163                /// Starts a new scope
    … …  
    180180                        scopes.pop_back();
    181181                }
    182                
     182
    183183                TypeMap() : voidValue( 0 ), pointerValue( 0 ), voidPointerValue( 0 ), functionPointerValue( 0 ), structValue(), unionValue(), enumValue(), scopes() {
    184184                        beginScope();
    … …  
    199199                        return searcher.find( key );
    200200                }
    201                
     201
    202202        }; // class TypeMap
    203203

  • src/ResolvExpr/Unify.cc

    r141b786 rb726084  
    7373                const OpenVarSet &openVars;
    7474                WidenMode widenMode;
    75                 Type *commonType;
    7675                const SymTab::Indexer &indexer;
    7776        };

  • src/SymTab/Validate.cc

    r141b786 rb726084  
    9494
    9595        /// Associates forward declarations of aggregates with their definitions
    96         class Pass2 : public Indexer {
     96        class Pass2 final : public Indexer {
    9797                typedef Indexer Parent;
    9898          public:
    9999                Pass2( bool doDebug, const Indexer *indexer );
    100100          private:
    101                 virtual void visit( StructInstType *structInst );
    102                 virtual void visit( UnionInstType *unionInst );
    103                 virtual void visit( TraitInstType *contextInst );
    104                 virtual void visit( StructDecl *structDecl );
    105                 virtual void visit( UnionDecl *unionDecl );
    106                 virtual void visit( TypeInstType *typeInst );
     101                using Indexer::visit;
     102                void visit( StructInstType *structInst ) final;
     103                void visit( UnionInstType *unionInst ) final;
     104                void visit( TraitInstType *contextInst ) final;
     105                void visit( StructDecl *structDecl ) final;
     106                void visit( UnionDecl *unionDecl ) final;
     107                void visit( TypeInstType *typeInst ) final;
    107108
    108109                const Indexer *indexer;
    … …  
    182183        };
    183184
    184         class CompoundLiteral : public GenPoly::DeclMutator {
     185        class CompoundLiteral final : public GenPoly::DeclMutator {
    185186                DeclarationNode::StorageClass storageclass = DeclarationNode::NoStorageClass;
    186187
    187                 virtual DeclarationWithType * mutate( ObjectDecl *objectDecl );
    188                 virtual Expression *mutate( CompoundLiteralExpr *compLitExpr );
     188                using GenPoly::DeclMutator::mutate;
     189                DeclarationWithType * mutate( ObjectDecl *objectDecl ) final;
     190                Expression *mutate( CompoundLiteralExpr *compLitExpr ) final;
    189191        };
    190192
    … …  
    652654        void EliminateTypedef::addImplicitTypedef( AggDecl * aggDecl ) {
    653655                if ( typedefNames.count( aggDecl->get_name() ) == 0 ) {
    654                         Type *type;
     656                        Type *type = nullptr;
    655657                        if ( StructDecl * newDeclStructDecl = dynamic_cast< StructDecl * >( aggDecl ) ) {
    656658                                type = new StructInstType( Type::Qualifiers(), newDeclStructDecl->get_name() );

  • src/driver/Makefile.am

    r141b786 rb726084  
    1111## Created On       : Sun May 31 08:49:31 2015
    1212## Last Modified By : Peter A. Buhr
    13 ## Last Modified On : Thu Jan 28 09:04:40 2016
    14 ## Update Count     : 7
     13## Last Modified On : Fri Oct 28 13:46:06 2016
     14## Update Count     : 10
    1515###############################################################################
    1616
    … …  
    2626cc1_SOURCES = cc1.cc
    2727
    28 cfa.cc : ${abs_top_srcdir}/version
    29         @true
    30 
    3128MAINTAINERCLEANFILES = @CFA_PREFIX@/bin/${bin_PROGRAMS} @CFA_PREFIX@/lib/${cc1lib_PROGRAMS}

  • src/driver/Makefile.in

    r141b786 rb726084  
    100100CFA_PREFIX = @CFA_PREFIX@
    101101CFLAGS = @CFLAGS@
    102 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    103102CPP = @CPP@
    104103CPPFLAGS = @CPPFLAGS@
    … …  
    543542
    544543
    545 cfa.cc : ${abs_top_srcdir}/version
    546         @true
    547 
    548544# Tell versions [3.59,3.63) of GNU make to not export all variables.
    549545# Otherwise a system limit (for SysV at least) may be exceeded.

  • src/driver/cfa.cc

    r141b786 rb726084  
    1010// Created On       : Tue Aug 20 13:44:49 2002
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Tue Oct 25 21:29:48 2016
    13 // Update Count     : 152
     12// Last Modified On : Thu Oct 27 22:19:37 2016
     13// Update Count     : 154
    1414//
    1515
    … …  
    5050
    5151
     52#define str(s) #s
     53
    5254int main( int argc, char *argv[] ) {
    53         string Version( CFA_VERSION_LONG );                                                     // current version number from CONFIG
    54         string Major( to_string( CFA_VERSION_MAJOR ) ), Minor( to_string( CFA_VERSION_MINOR ) ), Patch( to_string( CFA_VERSION_PATCH ) );
     55        string Version( CFA_VERSION_LONG );                                     // current version number from CONFIG
     56        string Major( str( CFA_VERSION_MAJOR ) ), Minor( str( CFA_VERSION_MINOR ) ), Patch( str( CFA_VERSION_PATCH ) );
    5557
    5658        string installincdir( CFA_INCDIR );                                     // fixed location of include files

  • src/examples/Makefile.in

    r141b786 rb726084  
    111111# applies to both programs
    112112CFLAGS = -g -Wall -Wno-unused-function # TEMPORARY: does not build with -O2
    113 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    114113CPP = @CPP@
    115114CPPFLAGS = @CPPFLAGS@

  • src/libcfa/Makefile.in

    r141b786 rb726084  
    137137CFA_PREFIX = @CFA_PREFIX@
    138138CFLAGS = -quiet -no-include-stdhdr -g -Wall -Wno-unused-function @CFA_FLAGS@ -B${abs_top_srcdir}/src/driver -XCFA -t # TEMPORARY: does not build with -O2
    139 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    140139CPP = @CPP@
    141140CPPFLAGS = @CPPFLAGS@

  • src/main.cc

    r141b786 rb726084  
    1010// Created On       : Fri May 15 23:12:02 2015
    1111// Last Modified By : Peter A. Buhr
    12 // Last Modified On : Mon Aug 29 17:34:39 2016
    13 // Update Count     : 426
     12// Last Modified On : Sun Oct 30 10:11:38 2016
     13// Update Count     : 435
    1414//
    1515
    … …  
    1818#include <signal.h>                                                                             // signal
    1919#include <getopt.h>                                                                             // getopt
    20 #include <execinfo.h>                                                                   // backtrace, backtrace_symbols_fd
     20#include <execinfo.h>                                                                   // backtrace, backtrace_symbols
    2121#include <cxxabi.h>                                                                             // __cxa_demangle
     22#include <cstring>                                                                              // index
    2223
    2324using namespace std;
    … …  
    7677static void dump( list< Declaration * > & translationUnit, ostream & out = cout );
    7778
    78 void backtrace( int start ) {                                                   // skip first N stack frames
     79static void backtrace( int start ) {                                    // skip first N stack frames
    7980        enum { Frames = 50 };
    8081        void * array[Frames];
    81         int size = backtrace( array, Frames );
    82         char ** messages = backtrace_symbols( array, size );
     82        int size = ::backtrace( array, Frames );
     83        char ** messages = ::backtrace_symbols( array, size ); // does not demangle names
     84
     85        *index( messages[0], '(' ) = '\0';                                      // find executable name
     86        cerr << "Stack back trace for: " << messages[0] << endl;
    8387
    8488        // skip last 2 stack frames after main
    … …  
    8690                char * mangled_name = nullptr, * offset_begin = nullptr, * offset_end = nullptr;
    8791                for ( char *p = messages[i]; *p; ++p ) {        // find parantheses and +offset
    88                         if (*p == '(') {
     92                        if ( *p == '(' ) {
    8993                                mangled_name = p;
    90                         } else if (*p == '+') {
     94                        } else if ( *p == '+' ) {
    9195                                offset_begin = p;
    92                         } else if (*p == ')') {
     96                        } else if ( *p == ')' ) {
    9397                                offset_end = p;
    9498                                break;
    … …  
    99103                int frameNo = i - start;
    100104                if ( mangled_name && offset_begin && offset_end && mangled_name < offset_begin ) {
    101                         *mangled_name++ = '\0';
     105                        *mangled_name++ = '\0';                                         // delimit strings
    102106                        *offset_begin++ = '\0';
    103107                        *offset_end++ = '\0';
    104108
    105                         int status, frameNo = i - start;
     109                        int status;
    106110                        char * real_name = __cxxabiv1::__cxa_demangle( mangled_name, 0, 0, &status );
     111                        // bug in __cxa_demangle for single-character lower-case non-mangled names
    107112                        if ( status == 0 ) {                                            // demangling successful ?
    108113                                cerr << "(" << frameNo << ") " << messages[i] << " : "
    109114                                         << real_name << "+" << offset_begin << offset_end << endl;
    110 
    111115                        } else {                                                                        // otherwise, output mangled name
    112116                                cerr << "(" << frameNo << ") " << messages[i] << " : "
    113                                          << mangled_name << "+" << offset_begin << offset_end << endl;
     117                                         << mangled_name << "(/*unknown*/)+" << offset_begin << offset_end << endl;
    114118                        } // if
     119
    115120                        free( real_name );
    116121                } else {                                                                                // otherwise, print the whole line
    … …  
    125130        cerr << "*CFA runtime error* program cfa-cpp terminated with "
    126131                 <<     (sig_num == SIGSEGV ? "segment fault" : "bus error")
    127                  << " backtrace:" << endl;
     132                 << "." << endl;
    128133        backtrace( 2 );                                                                         // skip first 2 stack frames
    129134        exit( EXIT_FAILURE );

  • src/tests/Makefile.in

    r141b786 rb726084  
    121121# applies to both programs
    122122CFLAGS = -g -Wall -Wno-unused-function @CFA_FLAGS@ # TEMPORARY: does not build with -O2
    123 CONFIG_STATUS_DEPENDENCIES = @CONFIG_STATUS_DEPENDENCIES@
    124123CPP = @CPP@
    125124CPPFLAGS = @CPPFLAGS@
Note: See TracChangeset for help on using the changeset viewer.