Changeset 27125d0 for doc/papers/concurrency/response2

Timestamp:

Jun 6, 2020, 4:59:19 PM (4 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

393d59a

Parents:

9246ec6

Message:

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

File:

• doc/papers/concurrency/response2 (modified) (8 diffs)

doc/papers/concurrency/response2

@@ -113 +113 @@
     OOPSLA 2017.
    
-Of our testing languages, only Java is JITTED. To ensure the Java test-programs
-correctly measured the specific feature, we consulted with Dave Dice at Oracle
-who works directly on the development of the Oracle JVM Just-in-Time
-Compiler. We modified our test programs based on his advise, and he validated
-our programs as correctly measuring the specified language feature. Hence, we
-have taken into account all issues related to performing benchmarks in JITTED
-languages.  Dave's help is recognized in the Acknowledgment section. Also, all
-the benchmark programs are publicly available for independent verification.
+Of our testing languages, only Java and Node.js are JITTED. To ensure the Java
+test-programs correctly measured the specific feature, we consulted with Dave
+Dice at Oracle who works directly on the development of the Oracle JVM
+Just-in-Time Compiler. We modified our test programs based on his advise, and
+he validated our programs as correctly measuring the specified language
+feature. Hence, we have taken into account all issues related to performing
+benchmarks in JITTED languages.  Dave's help is recognized in the
+Acknowledgment section. Also, all the benchmark programs are publicly available
+for independent verification.
+
+Similarly, we verified our Node.js programs with Gregor Richards, an expert in
+just-in-time compilation for dynamic typing.
 
 
@@ -286 +290 @@
 critical section); threads can arrive at any time in any order, where the
 mutual exclusion for the critical section ensures one thread executes at a
-time. Interestingly, Reed & Kanodia's mutual exclusion is Habermann's
-communication not mutual exclusion. These papers only buttress our contention
+time. Interestingly, Reed & Kanodia's critical region is Habermann's
+communication not critical section. These papers only buttress our contention
 about the confusion of these terms in the literature.
 
@@ -561 +565 @@
 
 I think we may be differing on the meaning of stack. You may be imagining a
-modern stack that grows and shrink dynamically. Whereas early Fortran
+modern stack that grows and shrinks dynamically. Whereas early Fortran
 preallocated a stack frame for each function, like Python allocates a frame for
 a generator.  Within each preallocated Fortran function is a frame for local
 variables and a pointer to store the return value for a call.  The Fortran
-call/return mechanism than uses these frames to build a traditional call stack
+call/return mechanism uses these frames to build a traditional call stack
 linked by the return pointer. The only restriction is that a function stack
 frame can only be used once, implying no direct or indirect recursion.  Hence,
@@ -631 +635 @@
     build coroutines by stacks of generators invoking one another.
 
-As we point out, coroutines built from stacks of generators have problems, such
-as no symmetric control-flow. Furthermore, stacks of generators have a problem
-with the following programming pattern.  logger is a library function called
-from a function or a coroutine, where the doit for the coroutine suspends. With
-stacks of generators, there has to be a function and generator version of
-logger to support these two scenarios. If logger is a library function, it may
-be impossible to create the generator logger because the logger function is
+Coroutines built from stacks of generators have problems, such as no symmetric
+control-flow. Furthermore, stacks of generators have a problem with the
+following programming pattern.  logger is a library function called from a
+function or a coroutine, where the doit for the coroutine suspends. With stacks
+of generators, there has to be a function and generator version of logger to
+support these two scenarios. If logger is a library function, it may be
+impossible to create the generator logger because the logger function is
 opaque.
 
@@ -668 +672 @@
   }
 
+Additonal text has been added to the start of Section 3.2 address this comment.
 
 
@@ -681 +686 @@
 
     * prefer generators for simple computations that yield up many values,
-
-This description does not cover output or matching generators that do not yield
-many or any values. For example, the output generator Fmt yields no value; the
-device driver yields a value occasionally once a message is found. Furthermore,
-real device drivers are not simple; there can have hundreds of states and
-transitions. Imagine the complex event-engine for a web-server written as a
-generator.
-
     * prefer coroutines for more complex processes that have significant
       internal structure,
 
-As for generators, complexity is not the criterion for selection. A coroutine
-brings generality to the implementation because of the addition stack, whereas
-generators have restrictions on standard software-engining practises: variable
-placement, no helper functions without creating an explicit generator stack,
-and no symmetric control-flow. Whereas, the producer/consumer example in Figure
-7 uses stack variable placement, helpers, and simple ping/pong-style symmetric
+We do not believe the number of values yielded is an important factor is
+choosing between a generator or coroutine; either form can receive (input) or
+return (output) millions of values. As well, simple versus complex computations
+is also not a criterion for selection as both forms can be very
+sophisticated. As stated in the paper, a coroutine brings generality to the
+implementation because of the addition stack, whereas generators have
+restrictions on standard software-engining practices: variable placement, no
+helper functions without creating an explicit generator stack, and no symmetric
 control-flow.
 
@@ -721 +720 @@
     in purpose.
 
-Given that you asked about this it before, I believe other readers might also
-ask the same question because async-await is very popular. So I think this
-section does help to position the work in the paper among other work, and
-hence, it is appropriate to keep it in the paper.
+Given that you asked about this before, I believe other readers might also ask
+the same question because async-await is very popular. So I think this section
+does help to position the work in the paper among other work, and hence, it is
+appropriate to keep it in the paper.
 
 
@@ -967 +966 @@
 
 To handle the other 5% of the cases, there is a trivial Cforall pattern
-providing Java-style start/join. The additional cost for this pattern is 2
-light-weight thread context-switches.
+providing Java-style start/join. The additional cost for this pattern is small
+in comparison to the work performed between the start and join.
 
   thread T {};