Index: doc/papers/concurrency/response2 =================================================================== --- doc/papers/concurrency/response2 (revision 04b4a7113ee67169f02e5f1dd053025c3ef887de) +++ doc/papers/concurrency/response2 (revision 27125d0c9173287e3672123b82e0967bb29c6bfa) @@ -113,12 +113,16 @@ 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,6 +290,6 @@ 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,9 +565,9 @@ 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,11 +635,11 @@ 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,4 +672,5 @@ } +Additonal text has been added to the start of Section 3.2 address this comment. @@ -681,21 +686,15 @@ * 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,8 +720,8 @@ 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,6 +966,6 @@ 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 {};