Ignore:
Timestamp:
Jun 6, 2020, 4:59:19 PM (18 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
arm-eh, jacob/cs343-translation, master, new-ast, new-ast-unique-expr
Children:
393d59a
Parents:
9246ec6
Message:

update concurrency paper to address referee comments and generate responses to comments

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/papers/concurrency/response2

    r9246ec6 r27125d0  
    113113    OOPSLA 2017.
    114114   
    115 Of our testing languages, only Java is JITTED. To ensure the Java test-programs
    116 correctly measured the specific feature, we consulted with Dave Dice at Oracle
    117 who works directly on the development of the Oracle JVM Just-in-Time
    118 Compiler. We modified our test programs based on his advise, and he validated
    119 our programs as correctly measuring the specified language feature. Hence, we
    120 have taken into account all issues related to performing benchmarks in JITTED
    121 languages.  Dave's help is recognized in the Acknowledgment section. Also, all
    122 the benchmark programs are publicly available for independent verification.
     115Of our testing languages, only Java and Node.js are JITTED. To ensure the Java
     116test-programs correctly measured the specific feature, we consulted with Dave
     117Dice at Oracle who works directly on the development of the Oracle JVM
     118Just-in-Time Compiler. We modified our test programs based on his advise, and
     119he validated our programs as correctly measuring the specified language
     120feature. Hence, we have taken into account all issues related to performing
     121benchmarks in JITTED languages.  Dave's help is recognized in the
     122Acknowledgment section. Also, all the benchmark programs are publicly available
     123for independent verification.
     124
     125Similarly, we verified our Node.js programs with Gregor Richards, an expert in
     126just-in-time compilation for dynamic typing.
    123127
    124128
     
    286290critical section); threads can arrive at any time in any order, where the
    287291mutual exclusion for the critical section ensures one thread executes at a
    288 time. Interestingly, Reed & Kanodia's mutual exclusion is Habermann's
    289 communication not mutual exclusion. These papers only buttress our contention
     292time. Interestingly, Reed & Kanodia's critical region is Habermann's
     293communication not critical section. These papers only buttress our contention
    290294about the confusion of these terms in the literature.
    291295
     
    561565
    562566I think we may be differing on the meaning of stack. You may be imagining a
    563 modern stack that grows and shrink dynamically. Whereas early Fortran
     567modern stack that grows and shrinks dynamically. Whereas early Fortran
    564568preallocated a stack frame for each function, like Python allocates a frame for
    565569a generator.  Within each preallocated Fortran function is a frame for local
    566570variables and a pointer to store the return value for a call.  The Fortran
    567 call/return mechanism than uses these frames to build a traditional call stack
     571call/return mechanism uses these frames to build a traditional call stack
    568572linked by the return pointer. The only restriction is that a function stack
    569573frame can only be used once, implying no direct or indirect recursion.  Hence,
     
    631635    build coroutines by stacks of generators invoking one another.
    632636
    633 As we point out, coroutines built from stacks of generators have problems, such
    634 as no symmetric control-flow. Furthermore, stacks of generators have a problem
    635 with the following programming pattern.  logger is a library function called
    636 from a function or a coroutine, where the doit for the coroutine suspends. With
    637 stacks of generators, there has to be a function and generator version of
    638 logger to support these two scenarios. If logger is a library function, it may
    639 be impossible to create the generator logger because the logger function is
     637Coroutines built from stacks of generators have problems, such as no symmetric
     638control-flow. Furthermore, stacks of generators have a problem with the
     639following programming pattern.  logger is a library function called from a
     640function or a coroutine, where the doit for the coroutine suspends. With stacks
     641of generators, there has to be a function and generator version of logger to
     642support these two scenarios. If logger is a library function, it may be
     643impossible to create the generator logger because the logger function is
    640644opaque.
    641645
     
    668672  }
    669673
     674Additonal text has been added to the start of Section 3.2 address this comment.
    670675
    671676
     
    681686
    682687    * prefer generators for simple computations that yield up many values,
    683 
    684 This description does not cover output or matching generators that do not yield
    685 many or any values. For example, the output generator Fmt yields no value; the
    686 device driver yields a value occasionally once a message is found. Furthermore,
    687 real device drivers are not simple; there can have hundreds of states and
    688 transitions. Imagine the complex event-engine for a web-server written as a
    689 generator.
    690 
    691688    * prefer coroutines for more complex processes that have significant
    692689      internal structure,
    693690
    694 As for generators, complexity is not the criterion for selection. A coroutine
    695 brings generality to the implementation because of the addition stack, whereas
    696 generators have restrictions on standard software-engining practises: variable
    697 placement, no helper functions without creating an explicit generator stack,
    698 and no symmetric control-flow. Whereas, the producer/consumer example in Figure
    699 7 uses stack variable placement, helpers, and simple ping/pong-style symmetric
     691We do not believe the number of values yielded is an important factor is
     692choosing between a generator or coroutine; either form can receive (input) or
     693return (output) millions of values. As well, simple versus complex computations
     694is also not a criterion for selection as both forms can be very
     695sophisticated. As stated in the paper, a coroutine brings generality to the
     696implementation because of the addition stack, whereas generators have
     697restrictions on standard software-engining practices: variable placement, no
     698helper functions without creating an explicit generator stack, and no symmetric
    700699control-flow.
    701700
     
    721720    in purpose.
    722721
    723 Given that you asked about this it before, I believe other readers might also
    724 ask the same question because async-await is very popular. So I think this
    725 section does help to position the work in the paper among other work, and
    726 hence, it is appropriate to keep it in the paper.
     722Given that you asked about this before, I believe other readers might also ask
     723the same question because async-await is very popular. So I think this section
     724does help to position the work in the paper among other work, and hence, it is
     725appropriate to keep it in the paper.
    727726
    728727
     
    967966
    968967To handle the other 5% of the cases, there is a trivial Cforall pattern
    969 providing Java-style start/join. The additional cost for this pattern is 2
    970 light-weight thread context-switches.
     968providing Java-style start/join. The additional cost for this pattern is small
     969in comparison to the work performed between the start and join.
    971970
    972971  thread T {};
Note: See TracChangeset for help on using the changeset viewer.