Changeset 016b1eb
- Timestamp:
- Jun 16, 2020, 9:09:53 PM (4 years ago)
- Branches:
- ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- c1ee231
- Parents:
- 9019b14
- Location:
- doc/papers/concurrency
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/papers/concurrency/Paper.tex
r9019b14 r016b1eb 292 292 293 293 \CFA~\cite{Moss18,Cforall} is a modern, polymorphic, non-object-oriented\footnote{ 294 \CFA has object-oriented features, such as constructors, destructors, virtualsand simple trait/interface inheritance.294 \CFA has object-oriented features, such as constructors, destructors, and simple trait/interface inheritance. 295 295 % Go interfaces, Rust traits, Swift Protocols, Haskell Type Classes and Java Interfaces. 296 296 % "Trait inheritance" works for me. "Interface inheritance" might also be a good choice, and distinguish clearly from implementation inheritance. 297 % You'll want to be a little bit careful with terms like "structural" and "nominal" inheritance as well. CFA has structural inheritance (I think Go as well) -- it's inferred based on the structure of the code. Java, Rust, and Haskell (not sure about Swift) have nominal inheritance, where there needs to be a specific statement that "this type inherits from this type". 298 However, functions \emph{cannot} be nested in structures, so there is no lexical binding between a structure and set of functions implemented by an implicit \lstinline@this@ (receiver) parameter.}, 297 % You'll want to be a little bit careful with terms like "structural" and "nominal" inheritance as well. CFA has structural inheritance (I think Go as well) -- it's inferred based on the structure of the code. 298 % Java, Rust, and Haskell (not sure about Swift) have nominal inheritance, where there needs to be a specific statement that "this type inherits from this type". 299 However, functions \emph{cannot} be nested in structures and there is no mechanism to designate a function parameter as a receiver, \lstinline@this@, parameter.}, 299 300 backwards-compatible extension of the C programming language. 300 301 In many ways, \CFA is to C as Scala~\cite{Scala} is to Java, providing a vehicle for new typing and control-flow capabilities on top of a highly popular programming language\footnote{ … … 317 318 Coroutines are only a stepping stone towards concurrency where the commonality is that coroutines and threads retain state between calls. 318 319 319 \Celeven /\CCeleven define concurrency~\cite[\S~7.26]{C11}, but it is largely wrappers for a subset of the pthreads library~\cite{Pthreads}.\footnote{Pthreads concurrency is based on simple thread fork and join in a function and mutex or condition locks, which is low-level and error-prone}320 \Celeven and \CCeleven define concurrency~\cite[\S~7.26]{C11}, but it is largely wrappers for a subset of the pthreads library~\cite{Pthreads}.\footnote{Pthreads concurrency is based on simple thread fork and join in a function and mutex or condition locks, which is low-level and error-prone} 320 321 Interestingly, almost a decade after the \Celeven standard, the most recent versions of gcc, clang, and msvc do not support the \Celeven include @threads.h@, indicating no interest in the C11 concurrency approach (possibly because of the recent effort to add concurrency to \CC). 321 322 While the \Celeven standard does not state a threading model, the historical association with pthreads suggests implementations would adopt kernel-level threading (1:1)~\cite{ThreadModel}, as for \CC. … … 392 393 \label{s:FundamentalExecutionProperties} 393 394 394 The features in a programming language should be composed froma set of fundamental properties rather than an ad hoc collection chosen by the designers.395 The features in a programming language should be composed of a set of fundamental properties rather than an ad hoc collection chosen by the designers. 395 396 To this end, the control-flow features created for \CFA are based on the fundamental properties of any language with function-stack control-flow (see also \uC~\cite[pp.~140-142]{uC++}). 396 The fundamental properties are execution state, thread, and mutual-exclusion/synchronization (MES).397 The fundamental properties are execution state, thread, and mutual-exclusion/synchronization. 397 398 These independent properties can be used to compose different language features, forming a compositional hierarchy, where the combination of all three is the most advanced feature, called a thread. 398 399 While it is possible for a language to only provide threads for composing programs~\cite{Hermes90}, this unnecessarily complicates and makes inefficient solutions to certain classes of problems. 399 400 As is shown, each of the non-rejected composed language features solves a particular set of problems, and hence, has a defensible position in a programming language. 400 If a compositional feature is missing, a programmer has too few fundamental properties resulting in a complex and/or i s inefficient solution.401 If a compositional feature is missing, a programmer has too few fundamental properties resulting in a complex and/or inefficient solution. 401 402 402 403 In detail, the fundamental properties are: 403 404 \begin{description}[leftmargin=\parindent,topsep=3pt,parsep=0pt] 404 405 \item[\newterm{execution state}:] 405 is the state information needed by a control-flow feature to initialize, manage compute data and execution location(s), and de-initialize, \eg calling a function initializes a stack frame including contained objects with constructors, manages local data in blocks and return locations during calls, and de-initializes the frame by running any object destructors and management operations. 406 is the state information needed by a control-flow feature to initialize and manage both compute data and execution location(s), and de-initialize. 407 For example, calling a function initializes a stack frame including contained objects with constructors, manages local data in blocks and return locations during calls, and de-initializes the frame by running any object destructors and management operations. 406 408 State is retained in fixed-sized aggregate structures (objects) and dynamic-sized stack(s), often allocated in the heap(s) managed by the runtime system. 407 409 The lifetime of state varies with the control-flow feature, where longer life-time and dynamic size provide greater power but also increase usage complexity and cost. … … 414 416 Multiple threads provide \emph{concurrent execution}; 415 417 concurrent execution becomes parallel when run on multiple processing units, \eg hyper-threading, cores, or sockets. 416 There must be language mechanisms to create, block and unblock, and join with a thread, even if the mechanism is indirect.417 418 \item[\newterm{ MES}:]419 is the concurrency mechanism sto perform an action without interruption and establish timing relationships among multiple threads.418 A programmer needs mechanisms to create, block and unblock, and join with a thread, even if these basic mechanisms are supplied indirectly through high-level features. 419 420 \item[\newterm{mutual-exclusion / synchronization (MES)}:] 421 is the concurrency mechanism to perform an action without interruption and establish timing relationships among multiple threads. 420 422 We contented these two properties are independent, \ie mutual exclusion cannot provide synchronization and vice versa without introducing additional threads~\cite[\S~4]{Buhr05a}. 421 Limiting MES , \eg no access to shared data,results in contrived solutions and inefficiency on multi-core von Neumann computers where shared memory is a foundational aspect of its design.423 Limiting MES functionality results in contrived solutions and inefficiency on multi-core von Neumann computers where shared memory is a foundational aspect of its design. 422 424 \end{description} 423 These properties are fundamental because they cannot be built from existing language features, \eg a basic programming language like C99~\cite{C99} cannot create new control-flow features, concurrency, or provide MES without atomichardware mechanisms.425 These properties are fundamental as they cannot be built from existing language features, \eg a basic programming language like C99~\cite{C99} cannot create new control-flow features, concurrency, or provide MES without (atomic) hardware mechanisms. 424 426 425 427 … … 443 445 \renewcommand{\arraystretch}{1.25} 444 446 %\setlength{\tabcolsep}{5pt} 447 \vspace*{-5pt} 445 448 \begin{tabular}{c|c||l|l} 446 449 \multicolumn{2}{c||}{execution properties} & \multicolumn{2}{c}{mutual exclusion / synchronization} \\ … … 461 464 Yes (stackful) & Yes & \textbf{11}\ \ \ @thread@ & \textbf{12}\ \ @mutex@ @thread@ \\ 462 465 \end{tabular} 466 \vspace*{-8pt} 463 467 \end{table} 464 468 … … 468 472 A @mutex@ structure, often called a \newterm{monitor}, provides a high-level interface for race-free access of shared data in concurrent programming-languages. 469 473 Case 3 is case 1 where the structure can implicitly retain execution state and access functions use this execution state to resume/suspend across \emph{callers}, but resume/suspend does not retain a function's local state. 470 A stackless structure, often called a \newterm{generator} or \emph{iterator}, is \newterm{stackless} because it still borrow the caller's stack and thread, but the stack is used only to preserve state across its callees not callers.474 A stackless structure, often called a \newterm{generator} or \emph{iterator}, is \newterm{stackless} because it still borrows the caller's stack and thread, but the stack is used only to preserve state across its callees not callers. 471 475 Generators provide the first step toward directly solving problems like finite-state machines that retain data and execution state between calls, whereas normal functions restart on each call. 472 476 Case 4 is cases 2 and 3 with thread safety during execution of the generator's access functions. … … 475 479 A stackful generator, often called a \newterm{coroutine}, is \newterm{stackful} because resume/suspend now context switch to/from the caller's and coroutine's stack. 476 480 A coroutine extends the state retained between calls beyond the generator's structure to arbitrary call depth in the access functions. 477 Cases 7 and 8are rejected because a new thread must have its own stack, where the thread begins and stack frames are stored for calls, \ie it is unrealistic for a thread to borrow a stack.478 Cases 9 and 10 are rejected because a thread needs a growable stack to accept calls, make calls, block, or be preempted, all of which compound to require an unknown amount of execution state.479 If this kind ofthread exists, it must execute to completion, \ie computation only, which severely restricts runtime management.481 Cases 7, 8, 9 and 10 are rejected because a new thread must have its own stack, where the thread begins and stack frames are stored for calls, \ie it is unrealistic for a thread to borrow a stack. 482 For cases 9 and 10, the stackless frame is not growable, precluding accepting nested calls, making calls, blocking as it requires calls, or preemption as it requires pushing an interrupt frame, all of which compound to require an unknown amount of execution state. 483 Hence, if this kind of uninterruptable thread exists, it must execute to completion, \ie computation only, which severely restricts runtime management. 480 484 Cases 11 and 12 are a stackful thread with and without safe access to shared state. 481 485 A thread is the language mechanism to start another thread of control in a program with growable execution state for call/return execution. … … 1396 1400 The call to @start@ is the first @resume@ of @prod@, which remembers the program main as the starter and creates @prod@'s stack with a frame for @prod@'s coroutine main at the top, and context switches to it. 1397 1401 @prod@'s coroutine main starts, creates local-state variables that are retained between coroutine activations, and executes $N$ iterations, each generating two random values, calling the consumer's @deliver@ function to transfer the values, and printing the status returned from the consumer. 1398 The producer call to @delivery@ transfers values into the consumer's communication variables, resumes the consumer, and returns the consumer status.1402 The producer's call to @delivery@ transfers values into the consumer's communication variables, resumes the consumer, and returns the consumer status. 1399 1403 Similarly on the first resume, @cons@'s stack is created and initialized, holding local-state variables retained between subsequent activations of the coroutine. 1400 1404 The symmetric coroutine cycle forms when the consumer calls the producer's @payment@ function, which resumes the producer in the consumer's delivery function. 1401 1405 When the producer calls @delivery@ again, it resumes the consumer in the @payment@ function. 1402 Both interface function than return to thetheir corresponding coroutine-main functions for the next cycle.1406 Both interface functions then return to their corresponding coroutine-main functions for the next cycle. 1403 1407 Figure~\ref{f:ProdConsRuntimeStacks} shows the runtime stacks of the program main, and the coroutine mains for @prod@ and @cons@ during the cycling. 1404 1408 As a consequence of a coroutine retaining its last resumer for suspending back, these reverse pointers allow @suspend@ to cycle \emph{backwards} around a symmetric coroutine cycle. … … 1414 1418 1415 1419 Terminating a coroutine cycle is more complex than a generator cycle, because it requires context switching to the program main's \emph{stack} to shutdown the program, whereas generators started by the program main run on its stack. 1416 Furthermore, each deallocated coroutine must execute all destructors for object allocated in the coroutine type \emph{and} allocated on the coroutine's stack at the point of suspension, which can be arbitrarily deep.1420 Furthermore, each deallocated coroutine must execute all destructors for objects allocated in the coroutine type \emph{and} allocated on the coroutine's stack at the point of suspension, which can be arbitrarily deep. 1417 1421 In the example, termination begins with the producer's loop stopping after N iterations and calling the consumer's @stop@ function, which sets the @done@ flag, resumes the consumer in function @payment@, terminating the call, and the consumer's loop in its coroutine main. 1418 1422 % (Not shown is having @prod@ raise a nonlocal @stop@ exception at @cons@ after it finishes generating values and suspend back to @cons@, which catches the @stop@ exception to terminate its loop.) … … 1438 1442 if @ping@ ends first, it resumes its starter the program main on return. 1439 1443 Regardless of the cycle complexity, the starter structure always leads back to the program main, but the path can be entered at an arbitrary point. 1440 Once back at the program main (creator), coroutines @ping@ and @pong@ are deallocated, runn ning any destructors for objects within the coroutine and possibly deallocating any coroutine stacks for non-terminated coroutines, where stack deallocation implies stack unwinding to find destructors for allocated objects on the stack.1441 Hence, the \CFA termination semantics for the generator and coroutine ensure correct deallocation sem natics, regardless of the coroutine's state (terminated or active), like any other aggregate object.1444 Once back at the program main (creator), coroutines @ping@ and @pong@ are deallocated, running any destructors for objects within the coroutine and possibly deallocating any coroutine stacks for non-terminated coroutines, where stack deallocation implies stack unwinding to find destructors for allocated objects on the stack. 1445 Hence, the \CFA termination semantics for the generator and coroutine ensure correct deallocation semantics, regardless of the coroutine's state (terminated or active), like any other aggregate object. 1442 1446 1443 1447 … … 1445 1449 1446 1450 A significant implementation challenge for generators and coroutines (and threads in Section~\ref{s:threads}) is adding extra fields to the custom types and related functions, \eg inserting code after/before the coroutine constructor/destructor and @main@ to create/initialize/de-initialize/destroy any extra fields, \eg the coroutine stack. 1447 There are several solutions to th eseproblem, which follow from the object-oriented flavour of adopting custom types.1451 There are several solutions to this problem, which follow from the object-oriented flavour of adopting custom types. 1448 1452 1449 1453 For object-oriented languages, inheritance is used to provide extra fields and code via explicit inheritance: … … 1480 1484 forall( `dtype` T | is_coroutine(T) ) void $suspend$( T & ), resume( T & ); 1481 1485 \end{cfa} 1482 Note, copying generators, coroutines, and threads is undefined because mul iple objects cannot execute on a shared stack and stack copying does not work in unmanaged languages (no garbage collection), like C, because the stack may contain pointers to objects within it that require updating for the copy.1486 Note, copying generators, coroutines, and threads is undefined because multiple objects cannot execute on a shared stack and stack copying does not work in unmanaged languages (no garbage collection), like C, because the stack may contain pointers to objects within it that require updating for the copy. 1483 1487 The \CFA @dtype@ property provides no \emph{implicit} copying operations and the @is_coroutine@ trait provides no \emph{explicit} copying operations, so all coroutines must be passed by reference or pointer. 1484 1488 The function definitions ensure there is a statically typed @main@ function that is the starting point (first stack frame) of a coroutine, and a mechanism to read the coroutine descriptor from its handle. … … 1625 1629 MyThread * team = factory( 10 ); 1626 1630 // concurrency 1627 ` delete( team );` $\C{// deallocate heap-based threads, implicit joins before destruction}\CRT$1631 `adelete( team );` $\C{// deallocate heap-based threads, implicit joins before destruction}\CRT$ 1628 1632 } 1629 1633 \end{cfa} … … 1702 1706 Unrestricted nondeterminism is meaningless as there is no way to know when a result is completed and safe to access. 1703 1707 To produce meaningful execution requires clawing back some determinism using mutual exclusion and synchronization, where mutual exclusion provides access control for threads using shared data, and synchronization is a timing relationship among threads~\cite[\S~4]{Buhr05a}. 1704 The shared data protected by mutual ex lusion is called a \newterm{critical section}~\cite{Dijkstra65}, and the protection can be simple, only 1 thread, or complex, only N kinds of threads, \eg group~\cite{Joung00} or readers/writer~\cite{Courtois71} problems.1708 The shared data protected by mutual exclusion is called a \newterm{critical section}~\cite{Dijkstra65}, and the protection can be simple, only 1 thread, or complex, only N kinds of threads, \eg group~\cite{Joung00} or readers/writer~\cite{Courtois71} problems. 1705 1709 Without synchronization control in a critical section, an arriving thread can barge ahead of preexisting waiter threads resulting in short/long-term starvation, staleness and freshness problems, and incorrect transfer of data. 1706 1710 Preventing or detecting barging is a challenge with low-level locks, but made easier through higher-level constructs. … … 1826 1830 \end{cquote} 1827 1831 The @dtype@ property prevents \emph{implicit} copy operations and the @is_monitor@ trait provides no \emph{explicit} copy operations, so monitors must be passed by reference or pointer. 1828 Similarly, the function definitions ensure sthere is a mechanism to read the monitor descriptor from its handle, and a special destructor to prevent deallocation if a thread is using the shared data.1832 Similarly, the function definitions ensure there is a mechanism to read the monitor descriptor from its handle, and a special destructor to prevent deallocation if a thread is using the shared data. 1829 1833 The custom monitor type also inserts any locks needed to implement the mutual exclusion semantics. 1830 1834 \CFA relies heavily on traits as an abstraction mechanism, so the @mutex@ qualifier prevents coincidentally matching of a monitor trait with a type that is not a monitor, similar to coincidental inheritance where a shape and playing card can both be drawable. … … 2479 2483 2480 2484 One scheduling solution is for the signaller S to keep ownership of all locks until the last lock is ready to be transferred, because this semantics fits most closely to the behaviour of single-monitor scheduling. 2481 However, this solution is inefficient if W2 waited first and can beimmediate passed @m2@ when released, while S retains @m1@ until completion of the outer mutex statement.2485 However, this solution is inefficient if W2 waited first and immediate passed @m2@ when released, while S retains @m1@ until completion of the outer mutex statement. 2482 2486 If W1 waited first, the signaller must retain @m1@ amd @m2@ until completion of the outer mutex statement and then pass both to W1. 2483 2487 % Furthermore, there is an execution sequence where the signaller always finds waiter W2, and hence, waiter W1 starves. 2484 To support th isefficient semantics and prevent barging, the implementation maintains a list of monitors acquired for each blocked thread.2488 To support these efficient semantics and prevent barging, the implementation maintains a list of monitors acquired for each blocked thread. 2485 2489 When a signaller exits or waits in a mutex function or statement, the front waiter on urgent is unblocked if all its monitors are released. 2486 Implementing a fast subset check for the necessar y released monitors is important and discussed in the following sections.2490 Implementing a fast subset check for the necessarily released monitors is important and discussed in the following sections. 2487 2491 % The benefit is encapsulating complexity into only two actions: passing monitors to the next owner when they should be released and conditionally waking threads if all conditions are met. 2488 2492 … … 2543 2547 Hence, function pointers are used to identify the functions listed in the @waitfor@ statement, stored in a variable-sized array. 2544 2548 Then, the same implementation approach used for the urgent stack (see Section~\ref{s:Scheduling}) is used for the calling queue. 2545 Each caller has a list of monitors acquired, and the @waitfor@ statement performs a short linear search matching functions in the @waitfor@ list with called functions, and then verifying the associated mutex locks can be transfer s.2549 Each caller has a list of monitors acquired, and the @waitfor@ statement performs a short linear search matching functions in the @waitfor@ list with called functions, and then verifying the associated mutex locks can be transferred. 2546 2550 2547 2551 … … 2778 2782 The \CFA program @main@ uses the call/return paradigm to directly communicate with the @GoRtn main@, whereas Go switches to the unbuffered channel paradigm to indirectly communicate with the goroutine. 2779 2783 Communication by multiple threads is safe for the @gortn@ thread via mutex calls in \CFA or channel assignment in Go. 2780 The differen tbetween call and channel send occurs for buffered channels making the send asynchronous.2781 In \CFA, asynchronous call and multiple buffers isprovided using an administrator and worker threads~\cite{Gentleman81} and/or futures (not discussed).2784 The difference between call and channel send occurs for buffered channels making the send asynchronous. 2785 In \CFA, asynchronous call and multiple buffers are provided using an administrator and worker threads~\cite{Gentleman81} and/or futures (not discussed). 2782 2786 2783 2787 Figure~\ref{f:DirectCommunicationDatingService} shows the dating-service problem in Figure~\ref{f:DatingServiceMonitor} extended from indirect monitor communication to direct thread communication. 2784 When converting a monitor to a thread (server), the coding pattern is to move as much code as possible from the accepted functions into the thread main so it does a nmuch work as possible.2788 When converting a monitor to a thread (server), the coding pattern is to move as much code as possible from the accepted functions into the thread main so it does as much work as possible. 2785 2789 Notice, the dating server is postponing requests for an unspecified time while continuing to accept new requests. 2786 2790 For complex servers, \eg web-servers, there can be hundreds of lines of code in the thread main and safe interaction with clients can be complex. … … 2790 2794 2791 2795 For completeness and efficiency, \CFA provides a standard set of low-level locks: recursive mutex, condition, semaphore, barrier, \etc, and atomic instructions: @fetchAssign@, @fetchAdd@, @testSet@, @compareSet@, \etc. 2792 Some of these low-level mechanism are used to build the \CFA runtime, but we always advocate using high-level mechanisms whenever possible.2796 Some of these low-level mechanisms are used to build the \CFA runtime, but we always advocate using high-level mechanisms whenever possible. 2793 2797 2794 2798 … … 2980 2984 2981 2985 To test the performance of the \CFA runtime, a series of microbenchmarks are used to compare \CFA with pthreads, Java 11.0.6, Go 1.12.6, Rust 1.37.0, Python 3.7.6, Node.js 12.14.1, and \uC 7.0.0. 2982 For comparison, the package must be multi-processor (M:N), which excludes libdil and /libmil~\cite{libdill} (M:1)), and use a shared-memory programming model, \eg not message passing.2986 For comparison, the package must be multi-processor (M:N), which excludes libdil and libmil~\cite{libdill} (M:1)), and use a shared-memory programming model, \eg not message passing. 2983 2987 The benchmark computer is an AMD Opteron\texttrademark\ 6380 NUMA 64-core, 8 socket, 2.5 GHz processor, running Ubuntu 16.04.6 LTS, and pthreads/\CFA/\uC are compiled with gcc 9.2.1. 2984 2988 … … 3049 3053 Figure~\ref{f:schedint} shows the code for \CFA, with results in Table~\ref{t:schedint}. 3050 3054 Note, the incremental cost of bulk acquire for \CFA, which is largely a fixed cost for small numbers of mutex objects. 3051 Java scheduling is significantly greater because the benchmark explicitly creates multiple thread in order to prevent the JIT from making the program sequential, \ie removing all locking.3055 Java scheduling is significantly greater because the benchmark explicitly creates multiple threads in order to prevent the JIT from making the program sequential, \ie removing all locking. 3052 3056 3053 3057 \begin{multicols}{2} … … 3308 3312 This type of concurrency can be achieved both at the language level and at the library level. 3309 3313 The canonical example of implicit concurrency is concurrent nested @for@ loops, which are amenable to divide and conquer algorithms~\cite{uC++book}. 3310 The \CFA language features should make it possible to develop a reasonable number of implicit concurrency mechanism to solve basic HPC data-concurrency problems.3314 The \CFA language features should make it possible to develop a reasonable number of implicit concurrency mechanisms to solve basic HPC data-concurrency problems. 3311 3315 However, implicit concurrency is a restrictive solution with significant limitations, so it can never replace explicit concurrent programming. 3312 3316 -
doc/papers/concurrency/figures/RunTimeStructure.fig
r9019b14 r016b1eb 8 8 -2 9 9 1200 2 10 6 3 855 2775 4155 292511 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 3 930 2850 30 30 3930 2850 3960 288012 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 4035 2850 30 30 4035 2850 4065 288010 6 3255 2475 3555 2625 11 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 3330 2550 30 30 3330 2550 3360 2580 12 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 3435 2550 30 30 3435 2550 3465 2580 13 13 -6 14 6 4 755 3525 5055 367515 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 4 830 3600 30 30 4830 3600 4860 363016 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 4 935 3600 30 30 4935 3600 4965 363014 6 4155 3225 4455 3375 15 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 4230 3300 30 30 4230 3300 4260 3330 16 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 4335 3300 30 30 4335 3300 4365 3330 17 17 -6 18 6 4 650 2775 4950 292519 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4 725 2850 15 15 4725 2850 4740 286520 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4 800 2850 15 15 4800 2850 4815 286521 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4 875 2850 15 15 4875 2850 4890 286518 6 4050 2475 4350 2625 19 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4125 2550 15 15 4125 2550 4140 2565 20 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4200 2550 15 15 4200 2550 4215 2565 21 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4275 2550 15 15 4275 2550 4290 2565 22 22 -6 23 6 3225 2400 3525 255024 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3300 2475 15 15 3300 2475 3315 249025 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3375 2475 15 15 3375 2475 3390 249026 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3450 2475 15 15 3450 2475 3465 249023 6 2625 2100 2925 2250 24 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 2700 2175 15 15 2700 2175 2715 2190 25 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 2775 2175 15 15 2775 2175 2790 2190 26 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 2850 2175 15 15 2850 2175 2865 2190 27 27 -6 28 6 5475 3450 5625 375029 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 5550 3525 15 15 5550 3525 5535 354030 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 5550 3600 15 15 5550 3600 5535 361531 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 5550 3675 15 15 5550 3675 5535 369028 6 4875 3150 5025 3450 29 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 4950 3225 15 15 4950 3225 4935 3240 30 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 4950 3300 15 15 4950 3300 4935 3315 31 1 3 0 1 -1 -1 0 0 20 0.000 1 4.7120 4950 3375 15 15 4950 3375 4935 3390 32 32 -6 33 6 4275 3525 4575 367534 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4350 3600 15 15 4350 3600 4365 361535 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4425 3600 15 15 4425 3600 4440 361536 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4500 3600 15 15 4500 3600 4515 361533 6 3675 3225 3975 3375 34 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3750 3300 15 15 3750 3300 3765 3315 35 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3825 3300 15 15 3825 3300 3840 3315 36 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3900 3300 15 15 3900 3300 3915 3315 37 37 -6 38 6 3225 4125 4650 442539 6 4350 4200 4650 435040 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4425 4275 15 15 4425 4275 4440 429041 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4500 4275 15 15 4500 4275 4515 429042 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 4575 4275 15 15 4575 4275 4590 429038 6 2625 3825 4050 4125 39 6 3750 3900 4050 4050 40 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3825 3975 15 15 3825 3975 3840 3990 41 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3900 3975 15 15 3900 3975 3915 3990 42 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 3975 3975 15 15 3975 3975 3990 3990 43 43 -6 44 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3450 4275 225 150 3450 4275 3675 442545 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4050 4275 225 150 4050 4275 4275 442544 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2850 3975 225 150 2850 3975 3075 4125 45 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3450 3975 225 150 3450 3975 3675 4125 46 46 -6 47 6 6 675 4125 7500 442548 6 7200 4200 7500 435049 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 7275 4275 15 15 7275 4275 7290 429050 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 7350 4275 15 15 7350 4275 7365 429051 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 7425 4275 15 15 7425 4275 7440 429047 6 6075 3825 6900 4125 48 6 6600 3900 6900 4050 49 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 6675 3975 15 15 6675 3975 6690 3990 50 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 6750 3975 15 15 6750 3975 6765 3990 51 1 3 0 1 -1 -1 0 0 20 0.000 1 0.0000 6825 3975 15 15 6825 3975 6840 3990 52 52 -6 53 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6 900 4275 225 150 6900 4275 7125 442553 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6300 3975 225 150 6300 3975 6525 4125 54 54 -6 55 6 6 675 3525 8025 397555 6 6075 3225 7425 3675 56 56 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 57 57 1 1 1.00 45.00 90.00 58 6 675 3750 6975 375058 6075 3450 6375 3450 59 59 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 60 60 1 1 1.00 45.00 90.00 61 7125 3750 7350 375061 6525 3450 6750 3450 62 62 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 63 7 800 3975 7800 3525 7350 3525 7350 3975 7800 397563 7200 3675 7200 3225 6750 3225 6750 3675 7200 3675 64 64 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 65 65 1 1 1.00 45.00 90.00 66 7 800 3750 8025 375066 7200 3450 7425 3450 67 67 -6 68 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5550 2625 150 150 5550 2625 5700 262569 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5550 3225 150 150 5550 3225 5700 322570 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 5550 3975 150 150 5550 3975 5700 397571 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3525 2850 150 150 3525 2850 3675 285072 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4200 2475 150 150 4200 2475 4350 247573 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4425 2850 150 150 4425 2850 4575 285074 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4 650 2475 150 150 4650 2475 4800 247575 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3 975 3600 150 150 3975 3600 4125 360076 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 3525 3600 30 30 3525 3600 3555 363077 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3 750 2475 150 150 3750 2475 3900 262578 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4 875 3600 150 150 4875 3600 5025 375079 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3 975 2850 150 150 3975 2850 4125 285080 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 7200 2775 150 150 7200 2775 7350 277581 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 2250 4830 30 30 2250 4830 2280 486082 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 7200 2775 30 30 7200 2775 7230 280583 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3525 3600 150 150 3525 3600 3675 360084 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3 875 4800 100 100 3875 4800 3975 480085 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4 650 4800 150 75 4650 4800 4800 487568 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 2325 150 150 4950 2325 5100 2325 69 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 2925 150 150 4950 2925 5100 2925 70 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4950 3675 150 150 4950 3675 5100 3675 71 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2925 2550 150 150 2925 2550 3075 2550 72 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3600 2175 150 150 3600 2175 3750 2175 73 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3825 2550 150 150 3825 2550 3975 2550 74 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4050 2175 150 150 4050 2175 4200 2175 75 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3375 3300 150 150 3375 3300 3525 3300 76 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 2925 3300 30 30 2925 3300 2955 3330 77 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3150 2175 150 150 3150 2175 3300 2325 78 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4275 3300 150 150 4275 3300 4425 3450 79 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3375 2550 150 150 3375 2550 3525 2550 80 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 6600 2475 150 150 6600 2475 6750 2475 81 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 1650 4530 30 30 1650 4530 1680 4560 82 1 3 0 1 0 0 0 0 0 0.000 1 0.0000 6600 2475 30 30 6600 2475 6630 2505 83 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 2925 3300 150 150 2925 3300 3075 3300 84 1 3 0 1 -1 -1 0 0 -1 0.000 1 0.0000 3275 4500 100 100 3275 4500 3375 4500 85 1 1 0 1 -1 -1 0 0 -1 0.000 1 0.0000 4050 4500 150 75 4050 4500 4200 4575 86 86 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 87 2400 4200 2400 3750 1950 3750 1950 4200 2400 420087 1800 3900 1800 3450 1350 3450 1350 3900 1800 3900 88 88 2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5 89 6300 4500 6300 1800 3000 1800 3000 4500 6300 450089 5700 4200 5700 1500 2400 1500 2400 4200 5700 4200 90 90 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 91 5 775 2850 5775 2400 5325 2400 5325 2850 5775 285091 5175 2550 5175 2100 4725 2100 4725 2550 5175 2550 92 92 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 93 5 775 4200 5775 3750 5325 3750 5325 4200 5775 420093 5175 3900 5175 3450 4725 3450 4725 3900 5175 3900 94 94 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 95 95 1 1 1.00 45.00 90.00 96 5175 3975 5325 397596 4575 3675 4725 3675 97 97 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 98 98 1 1 1.00 45.00 90.00 99 5175 3225 5325 322599 4575 2925 4725 2925 100 100 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 101 101 1 1 1.00 45.00 90.00 102 5175 2625 5325 2625102 4575 2325 4725 2325 103 103 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 104 104 1 1 1.00 45.00 90.00 105 5 775 3975 5925 3975105 5175 3675 5325 3675 106 106 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 107 107 1 1 1.00 45.00 90.00 108 5 775 3225 5925 3225108 5175 2925 5325 2925 109 109 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 110 110 1 1 1.00 45.00 90.00 111 5 775 2625 5925 2625111 5175 2325 5325 2325 112 112 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 113 5175 3975 5175 2625113 4575 3675 4575 2325 114 114 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 115 115 1 1 1.00 45.00 90.00 116 5 925 3975 5925 2025116 5325 3675 5325 1725 117 117 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 118 118 1 1 1.00 45.00 90.00 119 5 925 3750 6225 3750119 5325 3450 5625 3450 120 120 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 121 121 1 1 1.00 45.00 90.00 122 3450 2625 3225 2625122 2850 2325 2625 2325 123 123 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 3 124 124 1 1 1.00 45.00 90.00 125 5 925 2025 4200 2025 4200 2250125 5325 1725 3600 1725 3600 1950 126 126 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 127 3225 2625 3225 3600127 2625 2325 2625 3300 128 128 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 129 129 1 1 1.00 45.00 90.00 130 3075 3600 3375 3600130 2475 3300 2775 3300 131 131 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 132 132 1 1 1.00 45.00 90.00 133 3 675 3600 3825 3600133 3075 3300 3225 3300 134 134 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 135 135 1 1 1.00 45.00 90.00 136 4125 3600 4275 3600136 3525 3300 3675 3300 137 137 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 138 138 1 1 1.00 45.00 90.00 139 4575 3600 4725 3600139 3975 3300 4125 3300 140 140 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 141 141 1 1 1.00 45.00 90.00 142 5025 3600 5175 3600142 4425 3300 4575 3300 143 143 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 144 5 775 3450 5775 3000 5325 3000 5325 3450 5775 3450144 5175 3150 5175 2700 4725 2700 4725 3150 5175 3150 145 145 2 2 1 1 -1 -1 0 0 -1 4.000 0 0 0 0 0 5 146 8100 4500 8100 1800 6600 1800 6600 4500 8100 4500146 7500 4200 7500 1500 6000 1500 6000 4200 7500 4200 147 147 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 2 148 148 1 1 1.00 45.00 90.00 149 7050 2775 6825 2775149 6450 2475 6225 2475 150 150 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 0 0 2 151 6 825 2775 6825 3750151 6225 2475 6225 3450 152 152 2 1 0 1 -1 -1 0 0 -1 0.000 0 0 -1 1 0 4 153 153 1 1 1.00 45.00 90.00 154 7 875 3750 7875 2325 7200 2325 7200 2550154 7275 3450 7275 2025 6600 2025 6600 2250 155 155 2 2 0 1 -1 -1 0 0 -1 0.000 0 0 0 0 0 5 156 5 850 4950 5850 4725 5625 4725 5625 4950 5850 4950156 5250 4650 5250 4425 5025 4425 5025 4650 5250 4650 157 157 2 2 1 1 -1 -1 0 0 -1 3.000 0 0 0 0 0 5 158 6 975 4950 6750 4950 6750 4725 6975 4725 6975 4950159 4 1 -1 0 0 0 10 0.0000 2 105 720 5550 4425 Processors\001160 4 1 -1 0 0 0 10 0.0000 2 120 1005 4200 3225 Blocked Tasks\001161 4 1 -1 0 0 0 10 0.0000 2 150 870 4200 3975 Ready Tasks\001162 4 1 -1 0 0 0 10 0.0000 2 135 1095 7350 1725 Other Cluster(s)\001163 4 1 -1 0 0 0 10 0.0000 2 105 840 4 650 1725 User Cluster\001164 4 1 -1 0 0 0 10 0.0000 2 150 615 2175 3675 Manager\001165 4 1 -1 0 0 0 10 0.0000 2 105 990 2175 3525 Discrete-event\001166 4 1 -1 0 0 0 10 0.0000 2 135 795 2175 4350 preemption\001167 4 0 -1 0 0 0 10 0.0000 2 150 1 290 2325 4875 genrator/coroutine\001168 4 0 -1 0 0 0 10 0.0000 2 120 270 4050 4875 task\001169 4 0 -1 0 0 0 10 0.0000 2 105 450 7050 4875 cluster\001170 4 0 -1 0 0 0 10 0.0000 2 105 660 5 925 4875 processor\001171 4 0 -1 0 0 0 10 0.0000 2 105 555 4 875 4875 monitor\001158 6375 4650 6150 4650 6150 4425 6375 4425 6375 4650 159 4 1 -1 0 0 0 10 0.0000 2 105 720 4950 4125 Processors\001 160 4 1 -1 0 0 0 10 0.0000 2 120 1005 3600 2925 Blocked Tasks\001 161 4 1 -1 0 0 0 10 0.0000 2 150 870 3600 3675 Ready Tasks\001 162 4 1 -1 0 0 0 10 0.0000 2 135 1095 6750 1425 Other Cluster(s)\001 163 4 1 -1 0 0 0 10 0.0000 2 105 840 4050 1425 User Cluster\001 164 4 1 -1 0 0 0 10 0.0000 2 150 615 1575 3375 Manager\001 165 4 1 -1 0 0 0 10 0.0000 2 105 990 1575 3225 Discrete-event\001 166 4 1 -1 0 0 0 10 0.0000 2 135 795 1575 4050 preemption\001 167 4 0 -1 0 0 0 10 0.0000 2 150 1365 1725 4575 generator/coroutine\001 168 4 0 -1 0 0 0 10 0.0000 2 120 270 3450 4575 task\001 169 4 0 -1 0 0 0 10 0.0000 2 105 450 6450 4575 cluster\001 170 4 0 -1 0 0 0 10 0.0000 2 105 660 5325 4575 processor\001 171 4 0 -1 0 0 0 10 0.0000 2 105 555 4275 4575 monitor\001 -
doc/papers/concurrency/mail2
r9019b14 r016b1eb 934 934 Page 18, line 17: is using 935 935 936 937 938 Date: Tue, 16 Jun 2020 13:45:03 +0000 939 From: Aaron Thomas <onbehalfof@manuscriptcentral.com> 940 Reply-To: speoffice@wiley.com 941 To: tdelisle@uwaterloo.ca, pabuhr@uwaterloo.ca 942 Subject: SPE-19-0219.R2 successfully submitted 943 944 16-Jun-2020 945 946 Dear Dr Buhr, 947 948 Your manuscript entitled "Advanced Control-flow and Concurrency in Cforall" has been successfully submitted online and is presently being given full consideration for publication in Software: Practice and Experience. 949 950 Your manuscript number is SPE-19-0219.R2. Please mention this number in all future correspondence regarding this submission. 951 952 You can view the status of your manuscript at any time by checking your Author Center after logging into https://mc.manuscriptcentral.com/spe. If you have difficulty using this site, please click the 'Get Help Now' link at the top right corner of the site. 953 954 955 Thank you for submitting your manuscript to Software: Practice and Experience. 956 957 Sincerely, 958 959 Software: Practice and Experience Editorial Office 960 -
doc/papers/concurrency/response2
r9019b14 r016b1eb 27 27 thread creation and destruction? 28 28 29 The best description of Smalltalk concurrency I can find is in J. Hunt, 30 Smalltalk and Object Orientation, Springer-Verlag London Limited, 1997, Chapter 31 31 Concurrency in Smalltalk. It states on page 332: 32 33 For a process to be spawned from the current process there must be some way 34 of creating a new process. This is done using one of four messages to a 35 block. These messages are: 36 37 aBlock fork: This creates and schedules a process which will execute the 38 block. The priority of this process is inherited from the parent process. 39 ... 40 41 The Semaphore class provides facilities for achieving simple synchronization, 42 it is simple because it only allows for two forms of communication signal and 43 wait. 44 45 Hence, "aBlock fork" creates, "Semaphore" blocks/unblocks (as does message send 46 to an aBlock object), and garbage collection of an aBlock joins with its 47 thread. The fact that a programmer *implicitly* does "fork", "block"/"unblock", 48 and "join", does not change their fundamental requirement. 29 Fixed, changed sentence to: 30 31 A programmer needs mechanisms to create, block and unblock, and join with a 32 thread, even if these basic mechanisms are supplied indirectly through 33 high-level features. 49 34 50 35 … … 103 88 storage, too, which is a single instance across all generator instances of that 104 89 type, as for static storage in an object type. All the kinds of storage are 105 at play with semantics that is virtuallythe same as in other languages.90 at play with semantics that is the same as in other languages. 106 91 107 92 … … 118 103 Just-in-Time Compiler. We modified our test programs based on his advise, and 119 104 he validated our programs as correctly measuring the specified language 120 feature. Hence, we have taken into account all issues related to performing 121 benchmarks in JITTED languages. Dave's help is recognized in the 122 Acknowledgment section. Also, all the benchmark programs are publicly available 123 for independent verification. 124 125 Similarly, we verified our Node.js programs with Gregor Richards, an expert in 126 just-in-time compilation for dynamic typing. 105 feature. Dave's help is recognized in the Acknowledgment section. Similarly, 106 we verified our Node.js programs with Gregor Richards, an expert in 107 just-in-time compilation for dynamic typing. Hence, we have taken into account 108 all issues related to performing benchmarks in JITTED languages. Also, all the 109 benchmark programs are publicly available for independent verification. 127 110 128 111 … … 155 138 Since many aspects of Cforall are not OO, the rest of the paper *does* depend 156 139 on Cforall being identified as non-OO, otherwise readers would have 157 significantly different expectations for the design. We believe your definition 158 of OO is too broad, such as including C. Just because a programming language 159 can support aspects of the OO programming style, does not make it OO. (Just 160 because a duck can swim does not make it a fish.) 161 162 Our definition of non-OO follows directly from the Wikipedia entry: 163 164 Object-oriented programming (OOP) is a programming paradigm based on the 165 concept of "objects", which can contain data, in the form of fields (often 166 known as attributes or properties), and code, in the form of procedures 167 (often known as methods). A feature of objects is an object's procedures that 168 can access and often modify the data fields of the object with which they are 169 associated (objects have a notion of "this" or "self"). 170 https://en.wikipedia.org/wiki/Object-oriented_programming 171 172 Cforall fails this definition as code cannot appear in an "object" and there is 173 no implicit receiver. As well, Cforall, Go, and Rust do not have nominal 174 inheritance and they not considered OO languages, e.g.: 175 176 "**Is Go an object-oriented language?** Yes and no. Although Go has types and 177 methods and allows an object-oriented style of programming, there is no type 178 hierarchy. The concept of "interface" in Go provides a different approach 179 that we believe is easy to use and in some ways more general. There are also 180 ways to embed types in other types to provide something analogous-but not 181 identical-to subclassing. Moreover, methods in Go are more general than in 182 C++ or Java: they can be defined for any sort of data, even built-in types 183 such as plain, "unboxed" integers. They are not restricted to structs (classes). 184 https://golang.org/doc/faq#Is_Go_an_object-oriented_language 140 significantly different expectations for the design. We did not mean to suggest 141 that languages that support function pointers with structures support an OO 142 style. We revised the footnote to avoid this interpretation. Finally, Golang 143 does not identify itself as an OO language. 144 https://golang.org/doc/faq#Is_Go_an_object-oriented_language 185 145 186 146 … … 219 179 Whereas, the coroutine only needs the array allocated when needed. Now a 220 180 coroutine has a stack which occupies storage, but the maximum stack size only 221 needs to be the call chain allocating the most storage, where 181 needs to be the call chain allocating the most storage, whereas the generator 222 182 has a maximum size of all variable that could be created. 223 183 … … 314 274 315 275 \item[\newterm{execution state}:] is the state information needed by a 316 control-flow feature to initialize , managecompute data and execution317 location(s), and de-initialize , \eg calling a function initializes a stack318 frame including contained objects with constructors, manages local data in319 blocks and return locations during calls, and de-initializes the frame by276 control-flow feature to initialize and manage both compute data and execution 277 location(s), and de-initialize. For example, calling a function initializes a 278 stack frame including contained objects with constructors, manages local data 279 in blocks and return locations during calls, and de-initializes the frame by 320 280 running any object destructors and management operations. 321 281 … … 330 290 appropriate word? 331 291 292 332 293 "computation only" as opposed to what? 333 294 … … 335 296 i.e., the operation starts with everything it needs to compute its result and 336 297 runs to completion, blocking only when it is done and returns its result. 298 Computation only occurs in "embarrassingly parallel" problems. 337 299 338 300 … … 596 558 * coroutines/generators/threads: here there is some discussion, but it can 597 559 be improved. 598 * inter al/external scheduling: I didn't find any direct comparison between560 * internal/external scheduling: I didn't find any direct comparison between 599 561 these features, except by way of example. 600 562 … … 672 634 } 673 635 674 Additonal text has been added to the start of Section 3.2 address this comment. 636 Additional text has been added to the start of Section 3.2 addressing this 637 comment. 675 638 676 639 … … 787 750 and its shorthand form (not shown in the paper) 788 751 789 waitfor( remove, remove2 : t);790 791 A call to one these remove functions satisfies the waitfor (exact selection792 details are discussed in Section 6.4).752 waitfor( remove, remove2 : buffer ); 753 754 A call to either of these remove functions satisfies the waitfor (exact 755 selection details are discussed in Section 6.4). 793 756 794 757 … … 835 798 signal or signal_block. 836 799 800 837 801 I believe that one difference between the Go program and the Cforall 838 802 equivalent is that the Goroutine has an associated queue, so that … … 842 806 Actually, the buffer length is 0 for the Cforall call and the Go unbuffered 843 807 send so both are synchronous communication. 808 844 809 845 810 I think this should be stated explicitly. (Presumably, one could modify the … … 985 950 sout | "join"; 986 951 } 952 987 953 int main() { 988 954 T t[3]; // threads start and delay
Note: See TracChangeset
for help on using the changeset viewer.
