Ignore:
Timestamp:
Jun 24, 2020, 5:00:59 PM (4 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
c953163
Parents:
9791ab5 (diff), 7f9968a (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' into relaxed_ready

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/concurrency/response2

    r9791ab5 r8b58bae  
    2727      thread creation and destruction?
    2828
    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.
     29Fixed, 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.
    4934
    5035
     
    10388storage, too, which is a single instance across all generator instances of that
    10489type, as for static storage in an object type. All the kinds of storage are
    105 at play with semantics that is virtually the same as in other languages.
     90at play with semantics that is the same as in other languages.
    10691
    10792
     
    118103Just-in-Time Compiler. We modified our test programs based on his advise, and
    119104he 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.
     105feature. Dave's help is recognized in the Acknowledgment section.  Similarly,
     106we verified our Node.js programs with Gregor Richards, an expert in
     107just-in-time compilation for dynamic typing.  Hence, we have taken into account
     108all issues related to performing benchmarks in JITTED languages.  Also, all the
     109benchmark programs are publicly available for independent verification.
    127110
    128111
     
    155138Since many aspects of Cforall are not OO, the rest of the paper *does* depend
    156139on 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
     140significantly different expectations for the design. We did not mean to suggest
     141that languages that support function pointers with structures support an OO
     142style. We revised the footnote to avoid this interpretation. Finally, Golang
     143does not identify itself as an OO language.
     144https://golang.org/doc/faq#Is_Go_an_object-oriented_language
    185145
    186146
     
    219179Whereas, the coroutine only needs the array allocated when needed. Now a
    220180coroutine has a stack which occupies storage, but the maximum stack size only
    221 needs to be the call chain allocating the most storage, where as the generator
     181needs to be the call chain allocating the most storage, whereas the generator
    222182has a maximum size of all variable that could be created.
    223183
     
    314274
    315275 \item[\newterm{execution state}:] is the state information needed by a
    316  control-flow feature to initialize, manage compute data and execution
    317  location(s), and de-initialize, \eg calling a function initializes a stack
    318  frame including contained objects with constructors, manages local data in
    319  blocks and return locations during calls, and de-initializes the frame by
     276 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
    320280 running any object destructors and management operations.
    321281
     
    330290appropriate word?
    331291
     292
    332293    "computation only" as opposed to what?
    333294
     
    335296i.e., the operation starts with everything it needs to compute its result and
    336297runs to completion, blocking only when it is done and returns its result.
     298Computation only occurs in "embarrassingly parallel" problems.
    337299
    338300
     
    596558    * coroutines/generators/threads: here there is some discussion, but it can
    597559      be improved.
    598     * interal/external scheduling: I didn't find any direct comparison between
     560    * internal/external scheduling: I didn't find any direct comparison between
    599561      these features, except by way of example.
    600562
     
    672634  }
    673635
    674 Additonal text has been added to the start of Section 3.2 address this comment.
     636Additional text has been added to the start of Section 3.2 addressing this
     637comment.
    675638
    676639
     
    787750and its shorthand form (not shown in the paper)
    788751
    789   waitfor( remove, remove2 : t );
    790 
    791 A call to one these remove functions satisfies the waitfor (exact selection
    792 details are discussed in Section 6.4).
     752  waitfor( remove, remove2 : buffer );
     753
     754A call to either of these remove functions satisfies the waitfor (exact
     755selection details are discussed in Section 6.4).
    793756
    794757
     
    835798signal or signal_block.
    836799
     800
    837801    I believe that one difference between the Go program and the Cforall
    838802    equivalent is that the Goroutine has an associated queue, so that
     
    842806Actually, the buffer length is 0 for the Cforall call and the Go unbuffered
    843807send so both are synchronous communication.
     808
    844809
    845810    I think this should be stated explicitly. (Presumably, one could modify the
     
    985950      sout | "join";
    986951  }
     952
    987953  int main() {
    988954      T t[3]; // threads start and delay
Note: See TracChangeset for help on using the changeset viewer.