Changes in / [ab84e8a:d58a39a0]


Ignore:
Location:
doc/proposals/concurrency
Files:
5 deleted
3 edited

Legend:

Unmodified
Added
Removed

  • doc/proposals/concurrency/Makefile

    rab84e8a rd58a39a0  
    1212
    1313FIGURES = ${addsuffix .tex, \
    14         monitor \
    15         ext_monitor \
    1614}
    1715
    … …  
    3432
    3533clean :
    36         rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t *.cf *.glg *.glo *.gls *.ist *.acn *.acr *.alg \
     34        rm -f *.bbl *.aux *.dvi *.idx *.ilg *.ind *.brf *.out *.log *.toc *.blg *.pstex_t *.cf *.glg *.glo *.gls *.ist \
    3735                ${FIGURES} ${PICTURES} ${PROGRAMS} ${GRAPHS} ${basename ${DOCUMENT}}.ps ${DOCUMENT}
    3836
    … …  
    6058        # Run again to get index title into table of contents
    6159        ${LaTeX} ${basename $@}.tex
    62         -./bump_ver.sh
    6360        ${LaTeX} ${basename $@}.tex
    6461
    … …  
    7976        fig2dev -L pstex_t -p $@ $< > $@_t
    8077
    81 
    8278# Local Variables: #
    8379# compile-command: "make" #

  • doc/proposals/concurrency/concurrency.tex

    rab84e8a rd58a39a0  
    11% requires tex packages: texlive-base texlive-latex-base tex-common texlive-humanities texlive-latex-extra texlive-fonts-recommended
    22
    3 % inline code ©...© (copyright symbol) emacs: C-q M-)
    4 % red highlighting ®...® (registered trademark symbol) emacs: C-q M-.
    5 % blue highlighting ß...ß (sharp s symbol) emacs: C-q M-_
    6 % green highlighting ¢...¢ (cent symbol) emacs: C-q M-"
    7 % LaTex escape §...§ (section symbol) emacs: C-q M-'
    8 % keyword escape ¶...¶ (pilcrow symbol) emacs: C-q M-^
     3% inline code �...� (copyright symbol) emacs: C-q M-)
     4% red highlighting �...� (registered trademark symbol) emacs: C-q M-.
     5% blue highlighting �...� (sharp s symbol) emacs: C-q M-_
     6% green highlighting �...� (cent symbol) emacs: C-q M-"
     7% LaTex escape �...� (section symbol) emacs: C-q M-'
     8% keyword escape �...� (pilcrow symbol) emacs: C-q M-^
    99% math escape $...$ (dollar symbol)
    1010
    … …  
    2424\usepackage{graphicx}
    2525\usepackage{tabularx}
    26 \usepackage[acronym]{glossaries}
     26\usepackage{glossaries}
    2727\usepackage{varioref}                                                           % extended references
    2828\usepackage{inconsolata}
    … …  
    3333\usepackage[usenames]{color}
    3434\usepackage[pagewise]{lineno}
    35 \usepackage{fancyhdr}
    3635\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    3736\input{common}                                          % bespoke macros used in the document
    3837\usepackage[dvips,plainpages=false,pdfpagelabels,pdfpagemode=UseNone,colorlinks=true,pagebackref=true,linkcolor=blue,citecolor=blue,urlcolor=blue,pagebackref=true,breaklinks=true]{hyperref}
    3938\usepackage{breakurl}
    40 
    41 \usepackage{tikz}
    42 \def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;}
    4339
    4440\renewcommand{\UrlFont}{\small\sf}
    … …  
    7167\setcounter{secnumdepth}{3}                             % number subsubsections
    7268\setcounter{tocdepth}{3}                                % subsubsections in table of contents
    73 % \linenumbers                                            % comment out to turn off line numbering
    7469\makeindex
    75 \pagestyle{fancy}
    76 \fancyhf{}
    77 \cfoot{\thepage}
    78 \rfoot{v\input{version}}
    7970
    8071%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    9081\maketitle
    9182\section{Introduction}
    92 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.
    93 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.
    94 
    95 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.
     83This proposal provides a minimal core concurrency API that is both simple, efficient and can be reused to build "higher level" features. The simplest possible core is a thread and a lock but this low level approach is hard to master. An easier approach for users is be to support higher level construct as the basis of the concurrency in \CFA.
     84Indeed, for higly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading.
     85
     86There 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 ressource utilisation.
    9687
    9788\section{Concurrency}
    98 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.
    99 \\
     89Several tool can be used to solve concurrency challenges. Since these challenges always appear with the use of mutable shared state, some languages and libraries simply disallow mutable shared state completely (Erlang\cite{Erlang}, Haskell\cite{Haskell}, Akka (Scala)\cit). In the paradigms, interaction between concurrent objects rely on message passing or other paradigms that often closely relate to networking concepts. However, in imperative or OO languages these approaches entail a clear distinction between concurrent and non concurrent paradigms. Which in turns mean that programmers need to learn two sets of designs patterns in order to be effective at their jobs. Approaches based on shared memory are more closely related to non-concurrent paradigms since they often rely on non-concurrent constructs like routine calls and objects. At a lower level these can be implemented as locks and atomic operations. However for productivity reasons it is desireable to have a higher-level construct to be the core concurrency paradigm\cite{HPP:Study}. This paper proposes Monitors\cit as the core concurrency construct.
    10090
    10191Finally, 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.
    10292
    103 \subsection{Monitors}
    104 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 :
     93\section{Monitors}
     94A 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 to be able to declare a handle to a shared object and a set of routines that act on it :
    10595\begin{lstlisting}
    10696        typedef /*some monitor type*/ monitor;
    … …  
    113103\end{lstlisting}
    114104
    115 \subsubsection{Call semantics} \label{call}
    116 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.
    117 \\
    118 
    119 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 :
     105\subsection{Call semantics} \label{call}
     106The above example of monitors already displays some of their intrinsic caracteristics. Indeed, it is necessary to use pass-by-reference over pass-by-value for monitor routines. This semantics is important because since at their core, monitors are simply implicit mutual exclusion objects (locks) and copying semantics of these is ill defined. Therefore, monitors are implicitly non-copyable.
     107
     108Another aspect to consider is when a monitor acquires its mutual exclusion. Indeed, a monitor may need to be passed to helper routines that do not acquire the monitor mutual exclusion on entry. Examples of this can be both generic helper routines (\code{swap}, \code{sort}, etc.) or specific helper routines like the following example :
    120109
    121110\begin{lstlisting}
    122111        mutex struct counter_t { /*...*/ };
    123112
    124         void ?{}(counter_t & nomutex this);
     113        void ?{}(counter_t & mutex this);
    125114        int ++?(counter_t & mutex this);
    126         void ?{}(Int * this, counter_t & mutex cnt);
    127 \end{lstlisting}
    128 *semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
    129 \\
    130 
    131 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
    132 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.
    133 \\
     115        void ?{}(int * this, counter_t & mutex cnt);
     116
     117        bool is_zero(counter_t & nomutex this) {
     118                int val = this;
     119                return val == 0;
     120        }
     121\end{lstlisting}
     122*semantics of the declaration of \code{mutex struct counter_t} will be discussed in details in \ref{data}
     123
     124This is an example of a monitor used as safe(ish) counter for concurrency. This API, which offers the prefix increment operator and a conversion operator to \code{int}, guarantees that reading the value (by converting it to \code{int}) and incrementing it are mutually exclusive. Note that the \code{is_zero} routine uses the \code{nomutex} keyword. Indeed, since reading the value is already atomic, there is no point in maintaining the mutual exclusion once the value is copied locally (in the variable \code{val} ).
    134125
    135126Having 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.
    136 \\
    137127
    138128Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
    139129\begin{lstlisting}
    140         int f1(monitor & mutex m);
    141         int f2(const monitor & mutex m);
    142         int f3(monitor ** mutex m);
    143         int f4(monitor *[] mutex m);
    144         int f5(graph(monitor*) & mutex m);
    145 \end{lstlisting}
    146 
    147 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).
    148 
    149 \subsubsection{Data semantics} \label{data}
     130        int f01(monitor & mutex m);
     131        int f02(const monitor & mutex m);
     132        int f03(monitor * mutex m);
     133        int f04(monitor * mutex * m);
     134        int f05(monitor ** mutex m);
     135        int f06(monitor[10] mutex m);
     136        int f07(monitor[] mutex m);
     137        int f08(vector(monitor) & mutex m);
     138        int f09(list(monitor) & mutex m);
     139        int f10([monitor*, int] & mutex m);
     140        int f11(graph(monitor*) & mutex m);
     141\end{lstlisting}
     142
     143For the first few routines it seems to make sense to support the mutex keyword for such small variations. The difference between pointers and reference (\code{f01} vs \code{f03}) or const and non-const (\code{f01} vs \code{f02}) has no significance to mutual exclusion. It may not always make sense to acquire the monitor when extra dereferences (\code{f04}, \code{f05}) are added but it is still technically feasible and the present of the explicit mutex keywork does make it very clear of the user's intentions. Passing in a known-sized array(\code{f06}) is also technically feasible but is close to the limits. Indeed, the size of the array is not actually enforced by the compiler and if replaced by a variable-sized array (\code{f07}) or a higher-level container (\code{f08}, \code{f09}) it becomes much more complex to properly acquire all the locks needed for such a complex critical section. This implicit acquisition also poses the question of what qualifies as a container. If the mutex keyword is supported on monitors stored inside of other types it can quickly become complex and unclear which monitor should be acquired and when. The extreme example of this is \code{f11} which takes a possibly cyclic graph of pointers to monitors. With such a routine signature the intuition of which monitors will be acquired on entry is lost\cite{Chicken}. Where to draw the lines is up for debate but it seems reasonnable to consider \code{f03} as accepted and \code{f06} as rejected.
     144
     145\subsection{Data semantics} \label{data}
    150146Once the call semantics are established, the next step is to establish data semantics. Indeed, until now a monitor is used simply as a generic handle but in most cases monitors contian shared data. This data should be intrinsic to the monitor declaration to prevent any accidental use of data without its appripriate protection. For example here is a more fleshed-out version of the counter showed in \ref{call}:
    151147\begin{lstlisting}
    … …  
    154150        };
    155151
    156         void ?{}(counter_t & nomutex this) {
     152        void ?{}(counter_t & mutex this) {
    157153                this.cnt = 0;
    158154        }
    … …  
    169165Thread 1 & Thread 2 \\
    170166\begin{lstlisting}
    171         void f(counter_t & mutex c) {
     167        void main(counter_t & mutex c) {
    172168                for(;;) {
    173                         sout | (int)c | endl;
     169                        int count = c;
     170                        sout | count | endl;
    174171                }
    175172        }
    176173\end{lstlisting} &\begin{lstlisting}
    177         void g(counter_t & mutex c) {
     174        void main(counter_t & mutex c) {
    178175                for(;;) {
    179176                        ++c;
    … …  
    197194\end{lstlisting}
    198195
    199 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 :
     196This code acquires both locks before entering the critical section. In practice, writing multi-locking routines that can lead to deadlocks can be very tricky. Having language level support for such feature is therefore a significant asset for \CFA. However, as the this proposal shows, this does have significant repercussions relating to scheduling (see \ref{insched} and \ref{extsched}). The ability to acquire multiple monitors at the same time does incur a significant pitfall even without looking into scheduling. For example :
    200197\begin{lstlisting}
    201198        void foo(A & mutex a, B & mutex a) {
    … …  
    216213\end{lstlisting}
    217214
    218 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.
    219 
    220 \subsubsection{Implementation Details: Interaction with polymorphism}
    221 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.
    222 
    223 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.
    224 
    225 \subsection{Internal scheduling} \label{insched}
     215TODO: dig further into monitor order aquiring
     216
     217Thoughs : calls to \code{baz} and \code{bar} are definitely incompatible because they explicitly acquire locks in reverse order and therefore are explicitly asking for a deadlock. The best that can be done in this situatuin is to detect the deadlock. The case of implicit ordering is less clear because in the case of monitors the runtime system \textit{may} be smart enough to figure out that someone is waiting with explicit ordering... maybe.
     218
     219\subsubsection{Internal scheduling} \label{insched}
    226220Monitors 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 :
    227221
    … …  
    242236\end{lstlisting}
    243237
    244 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.
     238Here routine \code{foo} waits on the \code{signal} from \code{bar} before making further progress, effectively ensuring a basic ordering. This can easily be extended to multi-monitor calls by offering the same guarantee.
    245239
    246240\begin{center}
    … …  
    269263\end{center}
    270264
    271 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):
     265A 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 :
    272266
    273267\begin{center}
    … …  
    276270\hline
    277271\begin{lstlisting}
    278 condition e;
    279 
    280272void foo(monitor & mutex a,
    281273         monitor & mutex b) {
    282         wait(e);
     274        wait(a.e);
    283275}
    284276
    … …  
    290282foo(a,b);
    291283\end{lstlisting} &\begin{lstlisting}
    292 condition e;
    293 
    294284void bar(monitor & mutex a,
    295285         monitor & nomutex b) {
    … …  
    299289void foo(monitor & mutex a,
    300290         monitor & mutex b) {
    301         wait(e);
     291        wait(a.e);
    302292}
    303293
    304294bar(a, b);
    305295\end{lstlisting} &\begin{lstlisting}
    306 condition e;
    307 
    308296void bar(monitor & mutex a,
    309297         monitor & nomutex b) {
    … …  
    313301void baz(monitor & nomutex a,
    314302         monitor & mutex b) {
    315         wait(e);
     303        wait(a.e);
    316304}
    317305
    … …  
    322310
    323311This can be interpreted in two different ways :
    324 \begin{flushleft}
    325312\begin{enumerate}
    326         \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{ignoring} nested calls.
    327         \item \code{wait} atomically releases the monitors acquired by the inner-most routine, \underline{considering} nested calls.
     313        \item \code{wait} atomically releases the monitors \underline{theoretically} acquired by the inner-most mutex routine.
     314        \item \code{wait} atomically releases the monitors \underline{actually} acquired by the inner-most mutex routine.
    328315\end{enumerate}
    329 \end{flushleft}
    330 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. :
     316While 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.
    331317
    332318\begin{center}
    … …  
    348334\end{center}
    349335
    350 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.
     336This is not intuitive because even if both methods will display the same monitors state both inside and outside the critical section respectively, the behavior is different. Furthermore, the actual acquiring order will be exaclty the same since acquiring a monitor from inside its mutual exclusion is a no-op. This means that even if the data and the actual control flow are the same using both methods, the behavior of the \code{wait} will be different. The alternative is option 2, that is releasing \underline{actually} acquired monitors. This solves the issue of having the two acquiring method differ at the cost of making routine \code{foo} behave differently depending on from which context it is called (Context 1 or 2). Indeed in Context 2, routine \code{foo} will actually behave like routine \code{baz} rather than having the same behavior than in context 1. The fact that both implicit approaches can be unintuitive depending on the perspective may be a sign that the explicit approach is superior.
    351337\\
    352338
    … …  
    425411\\
    426412
    427 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 :
     413All these cases have there pros and cons. Case 1 is more distinct because it means programmers need to be carefull about where the condition was initialized as well as where it is used. On the other hand, it is very clear and explicit which monitor will be released and which monitor will stay acquired. This is similar to Case 2, which releases only the monitors explictly listed. However, in Case 2, calling the \code{wait} routine instead of the \code{waitRelease} routine will release all the acquired monitor. The Case 3 is an improvement on that since it releases all the monitors except those specified. The result is that the \code{wait} routine can be written as follows :
    428414\begin{lstlisting}
    429415void wait(condition & cond) {
    … …  
    433419This 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 :
    434420\begin{lstlisting}
    435 monitor global;
    436 
    437 extern void doStuff(); //uses global
     421extern void doStuff();
    438422
    439423void foo(monitor & mutex m) {
    … …  
    442426        //...
    443427}
    444 
    445 foo(global);
    446 \end{lstlisting}
    447 
    448 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 :
     428\end{lstlisting}
     429
     430Indeed, if Case 2 or 3 are chosen it any code can violate the mutual exclusion of calling code by issuing calls to \code{wait} or \code{waitHold} in a nested monitor context. Case 2 can be salvaged by removing the \code{wait} routine from the API but Case 3 cannot prevent users from calling \code{waitHold(someCondition, [])}. For this reason the syntax proposed in Case 3 is rejected. Note that syntaxes proposed in case 1 and 2 are not exclusive. Indeed, by supporting two types of condition as follows both cases can be supported :
    449431\begin{lstlisting}
    450432struct condition { /*...*/ };
    … …  
    461443\end{lstlisting}
    462444
    463 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.
     445Regardless of the option chosen for wait semantics, signal must be symmetrical. In all cases, signal only needs a single parameter, the condition variable that needs to be signalled. But \code{signal} needs to be called from the same monitor(s) than the call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
    464446
    465447Finally, 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.
    466 \\
    467448
    468449\subsection{External scheduling} \label{extsched}
    469 As one might expect, the alternative to Internal scheduling is to use External scheduling instead. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. Indeed, as the following examples will demonstrate, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (ex: \uC) or in terms of data (ex: Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the rest of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling with loose object definitions and multi-monitor routines. The following example shows what a simple use \code{accept} versus \code{wait}/\code{signal} and its advantages.
     450As one might expect, the alternative to Internal scheduling is to use External scheduling instead. This method is somewhat more robust to deadlocks since one of the threads keeps a relatively tight control on scheduling. Indeed, as the following examples will demontrate, external scheduling allows users to wait for events from other threads without the concern of unrelated events occuring. External scheduling can generally be done either in terms of control flow (see \uC) or in terms of data (see Go). Of course, both of these paradigms have their own strenghts and weaknesses but for this project control flow semantics where chosen to stay consistent with the reset of the languages semantics. Two challenges specific to \CFA arise when trying to add external scheduling which is 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.
    470451
    471452\begin{center}
    … …  
    477458                condition c;
    478459        public:
    479                 void f() { signal(c)}
    480                 void g() { wait(c); }
     460                void f();
     461                void g() { signal}
     462                void h() { wait(c); }
    481463        private:
    482464        }
    … …  
    486468        public:
    487469                void f();
    488                 void g() { _Accept(f); }
     470                void g();
     471                void h() { _Accept(g); }
    489472        private:
    490473        }
    … …  
    494477
    495478In 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.
    496 \\
    497479
    498480\subsubsection{Loose object definitions}
    499 In \uC, monitor declarations include an exhaustive list of monitor operations. Since \CFA is not object oriented it becomes both more difficult to implement but also less clear for the user :
     481In \uC monitor definitions include an exhaustive list of monitor operations. Since \CFA is not an object oriented it becomes much more difficult to implement but also much less clear for the user :
    500482
    501483\begin{lstlisting}
    … …  
    503485
    504486        void f(A & mutex a);
    505         void g(A & mutex a) { accept(f); }
    506 \end{lstlisting}
    507 
    508 However, external scheduling is an example where implementation constraints become visible from the interface. Indeed, ince there is no hard limit to the number of threads trying to acquire a monitor concurrently, performance is a significant concern. Here is the pseudo code for the entering phase of a monitor :
    509 
    510 \begin{center}
    511 \begin{tabular}{l}
    512 \begin{lstlisting}
    513         ¶if¶ critical section is free :
    514                 enter
    515         elif critical section accepts me :
    516                 enter
    517         ¶else¶ :
    518                 block
    519 \end{lstlisting}
    520 \end{tabular}
    521 \end{center}
    522 
    523 For the \code{critical section is free} condition it is easy to implement a check that can evaluate the condition in a few instruction. However, a fast check for \code{critical section accepts me} is much harder to implement depending on the constraints put on the monitors. Indeed, monitors are often expressed as an entry queue and some acceptor queue as in the following figure :
    524 
    525 \begin{center}
    526 {\resizebox{0.5\textwidth}{!}{\input{monitor}}}
    527 \end{center}
    528 
    529 There are other alternatives to these pictures but in the case of this picture implementing a fast accept check is relatively easy. Indeed simply updating a bitmask when the acceptor queue changes is enough to have a check that executes in a single instruction, even with a fairly large number of acceptor. However, this requires all the acceptable routines to be declared with the monitor declaration. For OO languages this doesn't compromise much since monitors already have an exhaustive list of member routines. However, for \CFA this isn't the case, routines can be added to a type anywhere after its declaration. A more flexible
    530 
    531 
    532 At this point we must make a decision between flexibility and performance. Many design decisions in \CFA achieve both flexibility and performance, for example polymorphic routines add significant flexibility but inlining them means the optimizer can easily remove any runtime cost.
    533 
    534 This approach leads to the \uC example being translated to :
     487        void g(A & mutex a);
     488        void h(A & mutex a) { accept(g); }
     489\end{lstlisting}
     490
     491While this is the direct translation of the \uC code, at the time of compiling routine \code{f} the \CFA does not already have a declaration of \code{g} while the \uC compiler does. This means that either the compiler has to dynamically find which routines are "acceptable" or the language needs a way of statically listing "acceptable" routines. Since \CFA has no existing concept that resemble dynamic routine definitions or pattern matching, the static approach seems the more consistent with the current language paradigms. This approach leads to the \uC example being translated to :
    535492\begin{lstlisting}
    536493        accept( void g(mutex struct A & mutex a) )
    … …  
    612569Note 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.
    613570
    614 \subsubsection{Implementation Details: External scheduling queues}
     571\subsection{Implementation Details}
     572\textbf{\large{Work in progress...}}
     573\subsubsection{Interaction with polymorphism}
     574At 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.
     575
     576First 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.
     577
     578\subsubsection{External scheduling queues}
    615579To support multi-monitor external scheduling means that some kind of entry-queues must be used that is aware of both monitors. However, acceptable routines must be aware of the entry queues which means they most be stored inside at least one of the monitors that will be acquired. This in turn adds the requirement a systematic algorithm of disambiguating which queue is relavant regardless of user ordering. The proposed algorithm is to fall back on monitors lock ordering and specify that the monitor that is acquired first is the lock with the relevant entry queue. This assumes that the lock acquiring order is static for the lifetime of all concerned objects gut that is a reasonnable contraint. This algorithm choice has two consequences, the ofthe highest priority monitor is no longer a true FIFO queue and the queue of the lowest priority monitor is both required and probably unused. The queue can no longer be a FIFO queue because instead of simply containing the waiting threads in order arrival, they also contain the second mutex. Therefore, another thread with the same highest priority monitor but a different lowest priority monitor may arrive first but enter the critical section after a thread with the correct pairing. Secondly, since it may not be known at compile time which monitor will be the lowest priority monitor, every monitor needs to have the correct queues even though it is probably that half the multi-monitor queues will go unused for the entire duration of the program.
    616580
    … …  
    624588
    625589Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}.
     590
    626591\subsection{Jobs and thread pools}
    627592The opposite approach is to base parallelism on \glspl{job}. Indeed, \glspl{job} offer limited flexibility but at the benefit of a simpler user interface. In \gls{job} based systems users express parallelism as units of work and the dependency graph (either explicit or implicit) that tie them together. This means users need not to worry about concurrency but significantly limits the interaction that can occur between different jobs. Indeed, any \gls{job} that blocks also blocks the underlying \gls{kthread}, this effectively mean the CPU utilization, and therefore throughput, will suffer noticeably. The golden standard of this implementation is Intel's TBB library\cite{TBB}.
    … …  
    632597
    633598\subsection{Paradigm performance}
    634 While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pin the performance implications of chosing a model at the language level. Indeed, in many situations own 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 fully armoticised by the actual work done.
    635 
    636 \section{\CFA 's Thread Building Blocks}
    637 As a system level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency. With this said, it is possible to deconstruct the three paradigms details aboved in order to get simple building blocks. Here is a table showing the core caracteristics of the mentionned paradigms :
     599While the choice between the three paradigms listed above can have significant performance implication, it is difficult to pin the performance implications of chosing a model at the language level. Indeed, in many situations own of these paradigms will show better performance but it all depends on the usage.
     600Having 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.
     601
     602\section{Parallelism in \CFA}
     603As a system level language, \CFA should offer both performance and flexibilty as its primary goals, simplicity and user-friendliness being a secondary concern. Therefore, the core of parallelism in \CFA should prioritize power and efficiency.
     604
     605\subsection{Kernel core}\label{kernel}
     606At the ro
     607\subsubsection{Threads}
     608\CFA threads have all the caracteristiques of
     609
     610\subsection{High-level options}\label{tasks}
     611
     612\subsubsection{Thread interface}
     613constructors destructors
     614        initializer lists
     615monitors
     616
     617\subsubsection{Futures}
     618
     619\subsubsection{Implicit threading}
     620Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level.
     621
    638622\begin{center}
    639 \begin{tabular}[t]{| r | c | c |}
    640 \cline{2-3}
    641 \multicolumn{1}{ c| }{} & Has a stack & Preemptive \\
    642 \hline
    643 \Glspl{job} & X & X \\
    644 \hline
    645 \Glspl{fiber} & \checkmark & X \\
    646 \hline
    647 \Glspl{uthread} & \checkmark & \checkmark \\
    648 \hline
     623\begin{tabular}[t]{|c|c|c|}
     624Sequential & System Parallel & Language Parallel \\
     625\begin{lstlisting}
     626void big_sum(int* a, int* b,
     627                 int* out,
     628                 size_t length)
     629{
     630        for(int i = 0; i < length; ++i ) {
     631                out[i] = a[i] + b[i];
     632        }
     633}
     634
     635
     636
     637
     638
     639int* a[10000];
     640int* b[10000];
     641int* c[10000];
     642//... fill in a and b ...
     643big_sum(a, b, c, 10000);
     644\end{lstlisting} &\begin{lstlisting}
     645void big_sum(int* a, int* b,
     646                 int* out,
     647                 size_t length)
     648{
     649        range ar(a, a + length);
     650        range br(b, b + length);
     651        range or(out, out + length);
     652        parfor( ai, bi, oi,
     653        [](int* ai, int* bi, int* oi) {
     654                oi = ai + bi;
     655        });
     656}
     657
     658int* a[10000];
     659int* b[10000];
     660int* c[10000];
     661//... fill in a and b ...
     662big_sum(a, b, c, 10000);
     663\end{lstlisting}&\begin{lstlisting}
     664void big_sum(int* a, int* b,
     665                 int* out,
     666                 size_t length)
     667{
     668        for (ai, bi, oi) in (a, b, out) {
     669                oi = ai + bi;
     670        }
     671}
     672
     673
     674
     675
     676
     677int* a[10000];
     678int* b[10000];
     679int* c[10000];
     680//... fill in a and b ...
     681big_sum(a, b, c, 10000);
     682\end{lstlisting}
    649683\end{tabular}
    650684\end{center}
    651685
    652 As shown in section \ref{cfaparadigms} these different blocks being available in \CFA it is trivial to reproduce any of these paradigm.
    653 
    654 \subsection{Thread Interface}
    655 The basic building blocks of \CFA are \glspl{cfathread}. By default these are implemented as \glspl{uthread} and as such offer a flexible and lightweight threading interface (lightweight comparatievely to \glspl{kthread}). A thread can be declared using a struct declaration prefix with the \code{thread} as follows :
    656 
    657 \begin{lstlisting}
    658         thread struct foo {};
    659 \end{lstlisting}
    660 
    661 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 :
    662 \begin{lstlisting}
    663         thread struct foo {};
    664 
    665         void ?main(thread foo* this) {
    666                 /*... Some useful code ...*/
    667         }
    668 \end{lstlisting}
    669 
    670 With these semantics it is trivial to write a thread type that takes a function pointer as parameter and executes it on its stack asynchronously :
    671 \begin{lstlisting}
    672         typedef void (*voidFunc)(void);
    673 
    674         thread struct FuncRunner {
    675                 voidFunc func;
    676         };
    677 
    678         //ctor
    679         void ?{}(thread FuncRunner* this, voidFunc inFunc) {
    680                 func = inFunc;
    681         }
    682 
    683         //main
    684         void ?main(thread FuncRunner* this) {
    685                 this->func();
    686         }
    687 \end{lstlisting}
    688 
    689 In this example \code{func} is a function pointer stored in \acrfull{tls}, which is \CFA is both easy to use and completly typesafe.
    690 
    691 Of course for threads to be useful, it must be possible to start and stop threads and wait for them to complete execution. While using \acrshort{api} such as \code{fork} and \code{join} is relatively common in the literature, such an interface is not needed. Indeed, the simplest approach is to use \acrshort{raii} principles and have threads \code{fork} once the constructor has completed and \code{join} before the destructor runs.
    692 \begin{lstlisting}
    693 thread struct FuncRunner; //FuncRunner declared above
    694 
    695 void world() {
    696         sout | "World!" | endl;
    697 }
    698 
    699 void main() {
    700         FuncRunner run = {world};
    701         //Thread run forks here
    702 
    703         //Print to "Hello " and "World!" will be run concurrently
    704         sout | "Hello " | endl;
    705 
    706         //Implicit join at end of scope
    707 }
    708 \end{lstlisting}
    709 This semantic has several advantages over explicit semantics : typesafety is guaranteed, any thread will always be started and stopped exaclty once and users can't make any progamming errors. Furthermore it naturally follows the memory allocation semantics which means users don't need to learn multiple semantics.
    710 
    711 These semantics also naturally scale to multiple threads meaning basic synchronisation is very simple :
    712 \begin{lstlisting}
    713         thread struct MyThread {
    714                 //...
    715         };
    716 
    717         //ctor
    718         void ?{}(thread MyThread* this) {}
    719 
    720         //main
    721         void ?main(thread MyThread* this) {
    722                 //...
    723         }
    724 
    725         void foo() {
    726                 MyThread thrds[10];
    727                 //Start 10 threads at the beginning of the scope
    728 
    729                 DoStuff();
    730 
    731                 //Wait for the 10 threads to finish
    732         }
    733 \end{lstlisting}
    734 
    735 \subsection{The \CFA Kernel : Processors, Clusters and Threads}\label{kernel}
    736 
    737 
    738 \subsection{Paradigms}\label{cfaparadigms}
    739 Given these building blocks we can then reproduce the all three of the popular paradigms. Indeed, we get \glspl{uthread} as the default paradigm in \CFA. However, disabling \glspl{preemption} on the \gls{cfacluster} means \glspl{cfathread} effectively become \glspl{fiber}. Since several \glspl{cfacluster} with different scheduling policy can coexist in the same application, this allows \glspl{fiber} and \glspl{uthread} to coexist in the runtime of an application.
    740 
    741 % \subsection{High-level options}\label{tasks}
    742 %
    743 % \subsubsection{Thread interface}
    744 % constructors destructors
    745 %       initializer lists
    746 % monitors
    747 %
    748 % \subsubsection{Futures}
    749 %
    750 % \subsubsection{Implicit threading}
    751 % Finally, simpler applications can benefit greatly from having implicit parallelism. That is, parallelism that does not rely on the user to write concurrency. This type of parallelism can be achieved both at the language level and at the system level.
    752 %
    753 % \begin{center}
    754 % \begin{tabular}[t]{|c|c|c|}
    755 % Sequential & System Parallel & Language Parallel \\
    756 % \begin{lstlisting}
    757 % void big_sum(int* a, int* b,
    758 %                int* out,
    759 %                size_t length)
    760 % {
    761 %       for(int i = 0; i < length; ++i ) {
    762 %               out[i] = a[i] + b[i];
    763 %       }
    764 % }
    765 %
    766 %
    767 %
    768 %
    769 %
    770 % int* a[10000];
    771 % int* b[10000];
    772 % int* c[10000];
    773 % //... fill in a and b ...
    774 % big_sum(a, b, c, 10000);
    775 % \end{lstlisting} &\begin{lstlisting}
    776 % void big_sum(int* a, int* b,
    777 %                int* out,
    778 %                size_t length)
    779 % {
    780 %       range ar(a, a + length);
    781 %       range br(b, b + length);
    782 %       range or(out, out + length);
    783 %       parfor( ai, bi, oi,
    784 %       [](int* ai, int* bi, int* oi) {
    785 %               oi = ai + bi;
    786 %       });
    787 % }
    788 %
    789 % int* a[10000];
    790 % int* b[10000];
    791 % int* c[10000];
    792 % //... fill in a and b ...
    793 % big_sum(a, b, c, 10000);
    794 % \end{lstlisting}&\begin{lstlisting}
    795 % void big_sum(int* a, int* b,
    796 %                int* out,
    797 %                size_t length)
    798 % {
    799 %       for (ai, bi, oi) in (a, b, out) {
    800 %               oi = ai + bi;
    801 %       }
    802 % }
    803 %
    804 %
    805 %
    806 %
    807 %
    808 % int* a[10000];
    809 % int* b[10000];
    810 % int* c[10000];
    811 % //... fill in a and b ...
    812 % big_sum(a, b, c, 10000);
    813 % \end{lstlisting}
    814 % \end{tabular}
    815 % \end{center}
    816 %
    817 % \subsection{Machine setup}\label{machine}
    818 % Threads are all good and well but wee still some OS support to fully utilize available hardware.
    819 %
    820 % \textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
    821 
    822 \section{Putting it all together}
     686\subsection{Machine setup}\label{machine}
     687Threads are all good and well but wee still some OS support to fully utilize available hardware.
     688
     689\textbf{\large{Work in progress...}} Do wee need something beyond specifying the number of kernel threads?
    823690
    824691\section{Future work}
    … …  
    829696
    830697\clearpage
    831 \printglossary[type=\acronymtype]
    832698\printglossary
    833699

  • doc/proposals/concurrency/glossary.tex

    rab84e8a rd58a39a0  
    3131\textit{Synonyms : Tasks.}
    3232}
    33 
    34 \longnewglossaryentry{cfacluster}
    35 {name={cluster}}
    36 {
    37 TBD...
    38 
    39 \textit{Synonyms : None.}
    40 }
    41 
    42 \longnewglossaryentry{cfacpu}
    43 {name={processor}}
    44 {
    45 TBD...
    46 
    47 \textit{Synonyms : None.}
    48 }
    49 
    50 \longnewglossaryentry{cfathread}
    51 {name={thread}}
    52 {
    53 TBD...
    54 
    55 \textit{Synonyms : None.}
    56 }
    57 
    58 \longnewglossaryentry{preemption}
    59 {name={preemption}}
    60 {
    61 TBD...
    62 
    63 \textit{Synonyms : None.}
    64 }
    65 
    66 \newacronym{tls}{TLS}{Thread Local Storage}
    67 \newacronym{api}{API}{Application Program Interface}
    68 \newacronym{raii}{RAII}{Ressource Acquisition Is Initialization}
Note: See TracChangeset for help on using the changeset viewer.