Changeset 9b4343e for doc/proposals


Ignore:
Timestamp:
Oct 13, 2016, 12:50:43 PM (5 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
a3eaa29
Parents:
a9aab60
Message:

Made significant changes to proposal and added simple version number

Location:
doc/proposals/concurrency
Files:
2 added
3 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/concurrency/.gitignore

    ra9aab60 r9b4343e  
    1717concurrency.pdf
    1818concurrency.ps
     19version.aux
  • doc/proposals/concurrency/Makefile

    ra9aab60 r9b4343e  
    5858        # Run again to get index title into table of contents
    5959        ${LaTeX} ${basename $@}.tex
     60        -./bump_ver.sh
    6061        ${LaTeX} ${basename $@}.tex
    6162
     
    7677        fig2dev -L pstex_t -p $@ $< > $@_t
    7778
     79
    7880# Local Variables: #
    7981# compile-command: "make" #
  • doc/proposals/concurrency/concurrency.tex

    ra9aab60 r9b4343e  
    3333\usepackage[usenames]{color}
    3434\usepackage[pagewise]{lineno}
     35\usepackage{fancyhdr}
    3536\renewcommand{\linenumberfont}{\scriptsize\sffamily}
    3637\input{common}                                          % bespoke macros used in the document
     
    7071\setcounter{secnumdepth}{3}                             % number subsubsections
    7172\setcounter{tocdepth}{3}                                % subsubsections in table of contents
     73\linenumbers                                            % comment out to turn off line numbering
    7274\makeindex
     75\pagestyle{fancy}
     76\fancyhf{}
     77\cfoot{\thepage}
     78\rfoot{v\input{version}}
    7379
    7480%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     
    8490\maketitle
    8591\section{Introduction}
    86 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 be to support higher level construct as the basis of the concurrency in \CFA.
    87 Indeed, for higly productive parallel programming high-level approaches are much more popular\cite{HPP:Study}. Examples are task based parallelism, message passing, implicit threading.
    88 
    89 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 ressource utilisation.
     92This 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.
     93Indeed, 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
     95There 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.
    9096
    9197\section{Concurrency}
    92 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 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.
     98Several 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)\cit). 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\cit as the core concurrency construct.
    9399
    94100Finally, 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.
    95101
    96102\section{Monitors}
    97 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 to be able to declare a handle to a shared object and a set of routines that act on it :
     103A 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 :
    98104\begin{lstlisting}
    99105        typedef /*some monitor type*/ monitor;
     
    107113
    108114\subsection{Call semantics} \label{call}
    109 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 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.
    110 
    111 Another 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 :
     115The 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.
     116
     117Another 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 :
    112118
    113119\begin{lstlisting}
    114120        mutex struct counter_t { /*...*/ };
    115121
    116         void ?{}(counter_t & mutex this);
     122        void ?{}(counter_t & nomutex this);
    117123        int ++?(counter_t & mutex this);
    118         void ?{}(int * this, counter_t & mutex cnt);
    119 
    120         bool is_zero(counter_t & nomutex this) {
    121                 int val = this;
    122                 return val == 0;
    123         }
    124 \end{lstlisting}
    125 *semantics of the declaration of \code{mutex struct counter_t} will be discussed in details in \ref{data}
    126 
    127 This 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} ).
     124        void ?{}(Int * this, counter_t & mutex cnt);
     125\end{lstlisting}
     126*semantics of the declaration of \code{mutex struct counter_t} are discussed in details in section \ref{data}
     127
     128This 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
     129uses \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.
    128130
    129131Having 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.
     
    131133Regardless of which keyword is kept, it is important to establish when mutex/nomutex may be used depending on type parameters.
    132134\begin{lstlisting}
    133         int f01(monitor & mutex m);
    134         int f02(const monitor & mutex m);
    135         int f03(monitor * mutex m);
    136         int f04(monitor * mutex * m);
    137         int f05(monitor ** mutex m);
    138         int f06(monitor[10] mutex m);
    139         int f07(monitor[] mutex m);
    140         int f08(vector(monitor) & mutex m);
    141         int f09(list(monitor) & mutex m);
    142         int f10([monitor*, int] & mutex m);
    143         int f11(graph(monitor*) & mutex m);
    144 \end{lstlisting}
    145 
    146 For 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.
     135        int f1(monitor & mutex m);
     136        int f2(const monitor & mutex m);
     137        int f3(monitor ** mutex m);
     138        int f4(monitor *[] mutex m);
     139        int f5(graph(monitor*) & mutex m);
     140\end{lstlisting}
     141
     142The 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 exhastive list of objects to acquire on entering. Adding references (\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, this projects to imposes the requirement that a routine may only acquire one monitor per parameter and it must be the type of the parameter with potential qualifiers and references.
    147143
    148144\subsection{Data semantics} \label{data}
     
    153149        };
    154150
    155         void ?{}(counter_t & mutex this) {
     151        void ?{}(counter_t & nomutex this) {
    156152                this.cnt = 0;
    157153        }
     
    168164Thread 1 & Thread 2 \\
    169165\begin{lstlisting}
    170         void main(counter_t & mutex c) {
     166        void f(counter_t & mutex c) {
    171167                for(;;) {
    172                         int count = c;
    173                         sout | count | endl;
     168                        sout | (int)c | endl;
    174169                }
    175170        }
    176171\end{lstlisting} &\begin{lstlisting}
    177         void main(counter_t & mutex c) {
     172        void g(counter_t & mutex c) {
    178173                for(;;) {
    179174                        ++c;
     
    197192\end{lstlisting}
    198193
    199 This 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 :
     194This 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, 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 :
    200195\begin{lstlisting}
    201196        void foo(A & mutex a, B & mutex a) {
     
    216211\end{lstlisting}
    217212
     213% TODO
    218214TODO: dig further into monitor order aquiring
    219215
     
    239235\end{lstlisting}
    240236
    241 Here 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.
     237Here 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.
    242238
    243239\begin{center}
     
    266262\end{center}
    267263
    268 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 :
     264A 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 here, only routines the acquire mutual exclusion have an impact on internal scheduling):
    269265
    270266\begin{center}
     
    273269\hline
    274270\begin{lstlisting}
     271condition e;
     272
    275273void foo(monitor & mutex a,
    276274         monitor & mutex b) {
    277         wait(a.e);
     275        wait(e);
    278276}
    279277
     
    285283foo(a,b);
    286284\end{lstlisting} &\begin{lstlisting}
     285condition e;
     286
    287287void bar(monitor & mutex a,
    288288         monitor & nomutex b) {
     
    292292void foo(monitor & mutex a,
    293293         monitor & mutex b) {
    294         wait(a.e);
     294        wait(e);
    295295}
    296296
    297297bar(a, b);
    298298\end{lstlisting} &\begin{lstlisting}
     299condition e;
     300
    299301void bar(monitor & mutex a,
    300302         monitor & nomutex b) {
     
    304306void baz(monitor & nomutex a,
    305307         monitor & mutex b) {
    306         wait(a.e);
     308        wait(e);
    307309}
    308310
     
    314316This can be interpreted in two different ways :
    315317\begin{enumerate}
    316         \item \code{wait} atomically releases the monitors \underline{theoretically} acquired by the inner-most mutex routine.
    317         \item \code{wait} atomically releases the monitors \underline{actually} acquired by the inner-most mutex routine.
     318        \item \code{wait} atomically releases the monitors acquired by the inner-most mutex routine, \underline{ignoring} nested calls.
     319        \item \code{wait} atomically releases the monitors acquired by the inner-most mutex routine, \underline{considering} nested calls.
    318320\end{enumerate}
    319321While 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.
     
    337339\end{center}
    338340
    339 This 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.
     341This 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.
    340342\\
    341343
     
    414416\\
    415417
    416 All 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 :
     418All these cases have there 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 explicit 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 :
    417419\begin{lstlisting}
    418420void wait(condition & cond) {
     
    422424This 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 :
    423425\begin{lstlisting}
    424 extern void doStuff();
     426monitor global;
     427
     428extern void doStuff(); //uses global
    425429
    426430void foo(monitor & mutex m) {
     
    429433        //...
    430434}
    431 \end{lstlisting}
    432 
    433 Indeed, 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 :
     435
     436foo(global);
     437\end{lstlisting}
     438
     439Indeed, 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 :
    434440\begin{lstlisting}
    435441struct condition { /*...*/ };
     
    446452\end{lstlisting}
    447453
    448 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) than the call to \code{wait}. Otherwise, mutual exclusion cannot be properly transferred back to the waiting monitor.
     454Regardless 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.
    449455
    450456Finally, 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.
     
    591597
    592598Examples of languages that support are Java\cite{Java}, Haskell\cite{Haskell} and \uC\cite{uC++book}.
    593 
    594599\subsection{Jobs and thread pools}
    595600The 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}.
     
    627632\end{lstlisting}
    628633
    629 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 function 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 :
     634Obviously, 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 :
    630635\begin{lstlisting}
    631636        thread struct foo {};
Note: See TracChangeset for help on using the changeset viewer.