Slides:

Slides available here

Questions:

Michael DiBernardo:

The authors state at the bottom of the second page that "one penalty for adopting cooperative task management is that every IO library function must be wrapped so that..." Is this penalty really all that severe? This sounds more like a minor implementation detail than a serious performance issue.

In practice, when input is handled asynchronously, how often is it really possible for the task to continue to perform meaningful work without actually having the input available to it?

The authors argue that lack of closure support in C++ forces developers to do a lot of manual stack management. However, there are several high-quality closure implementations available for C++: Does this weaken the effectiveness of their argument? How much of the work presented here is simply an effort to work around deficiencies in the target language rather than deficiencies in the event- and thread-based models?

How does the use of the adapters described in section 4 affect the ability of the programmer to debug problems that call code through these adapters?

Sam Davis:

The hybrid approach creates so much unnecessary complexity (and inefficiency) that it's hard to imagine using it except when incorporating legacy code written in the other style. Isn't it fundamentally bad to combine two very different programming styles in this way?

Does the Pinning Pattern imply that the same I/O operation could be repeated an arbitrary number of times? If so, is this a reasonable thing to do?

Aiman Erbad:

Can we improve threads to implement cooperative multi-tasking instead of adding another level of abstraction in Fibers?

What is the importance of the short circuit branch in the wrapper?

Wilson Fung:

Is there any attempt in using cooperative task management with multiprocessor system?

Why would mixing event-driven programming and thread-based programming be a good idea?

Ivan Sham:

The paper mentioned two synchronization mechanisms. Can you explain how the optimistic synchronization mechanism work? It seems to be quite wasteful to compute something speculatively and check to see if it's valid.

Can there be other combinations of task and stack management? Is it possible to construct a programming scheme by randomly picking a task/stack management styles? What happens with the combination of preemptive task management with manual stack management?

Ali Bakhoda:

Can you explain more about continuations and their effect on the readability of the code?

Can you explain more about the "pinning pattern" technique that they use to avoid the need to block on I/O? Does it have any special drawback?

Haoran Song:

For the Data Partitioning, it seems that the more you break up your shared state, the fewer conflicts you should have. Is that always true? In my experience, it is opposite. More breaking up also means more chances to get conflicts? What do you think?

In order to achieve cooperative task management with automatic stack management, all I/O must be asynchronous to work in this model. Could you explain the reason? I am a little confused about this part.

Mirna Limic :

The way I learned multiprogramming is only in the context of pessimistic synchronization algorithms. Would you happen to know if any modern operating systems use optimistic synchronization algorithms? Why would a system use optimistic synchronization?

Considering all of the work they have done in wrapping I/O functions would you say that the ease of implementation is closer to the event-driven or multithreaded systems?

To benchmark the cooperative task management implemented on two systems to other operating systems the authors use the following sentence: "Our experience with both systems has been positive and our subjective impression is that we have been able to preempt many subtle concurrency problems by using cooperative task management as the basis for our work." What could be the types of statistics comparing cooperative task management to the event-driven and multithreaded systems that someone interested in implementing cooperative task management would like to see?

Nguyet Nguyen:

What are the advantages of the combination of cooperative task management and automatic stack management?

Why do we need to change the manual stack management in even-driven programming to the automatic stack management?

Kevin Loken:

Are fibers (cooperative multitasking in windows) an equivalent of event based programming, with a message queue just managed by the stack of MainFibre?

In the discussion on manual stack ripping, the authors discuss having to rip up the call graph to the point where a rip/split/continuation is already in place as soon as a blocking call is entered in to a function. Is there any other way of dealing with this? Or is this specific just to languages like C/C++ ... if an explicit 'continuation' facility exists in a language.

Seonah Lee:

Would you explain why automatic stack management is related to multi-threading and manual stack management is to event-handling based on the code in Section 3.1?

"fibers", mentioned in Section 4, are coined by the authors or already known?

Billy Cheung:

Regarding the concept of cooperative task management and how the authors implemented it, the authors made use of fibers while making sure that any potentially blocking I/Os will not be handled in the main fiber. While this is of course understandable in that there are indeed certain things that has to be done via blocking I/Os, could this also be a way to prevent supposedly 'cooperative' threads who decide to be selfish and never yield from mucking everyone up?

The authors stated rather explicitly how their vision differs from the Lauer and Needham definition of event and thread models. Given that there is an almost 30 year gap between the two, it is clearly not due to the papers being contemporary and thus referring each other. Why do you suppose they had to make such a stark statement?

Mehmet Alparslan:

In the example ,manual is calling atomic, what mechanism is used to yield for(switching from I/O to main fiber) in VerifyCert? (I`m a bit lost on this since VerifyCert is an automatic stack procedure, is it verifyFiber`s job to detect the block?)

The "Pinning Pattern" used avoid concurrency problems in system loops over all the functions using a pinned resource and restarts the execution until it finds a path of executed functions where no function yields. This solution appears to be inefficient in terms of time. Are aware of any other solutions dependent on the restart mechanism but using some heuristics?

Alfred Yu-Han Pang:

Is event-driven programming the modern equivalent of "spaghetti code" that used to be characteristic of using GOTOs? Dijkstra's probably turning in his grave from the mess of event-driven programming has created.

While the adaptors show that the two paradigms can work with each other in the same code, where would you do something like this, other than an academic paper such as this?

What particular advantages does cooperative task management have over regular threaded programming? Is cooperative task management just a fancy name for a scheduling system that essentially lets tasks run to completion? How are co-routines similar/different than CTM as described by the paper?

Gary Huang:

The paper applied the hybrid approach. In the context, can event-driven programming and threaded programming apply hybrid approach? Can we say the "sweet spot" a hybrid of both programming styles?

If we use C++ to program, what is the manual stack management to yield for I/O operations?

Erica Zhang:

Could you analysis the performance of the cooperative task management with automatic stack management, compared with event-driven programming and multithread programming ?

What are the potential disadvantages of this scheme ?

Mayukh Saubhasik:

How does one handle the problem of enforcement of scheduling decisions in a purely cooperative scheduling scheme ? (or is it that a cooperative scheduling scheme should always be modeled on top of a preemptive scheduling scheme?)

How does the "Pinning Design Pattern" , mentioned in the paper work ? How would it be used with common forms of IO like secondary storage, user input or network input ?

Lloyd Markle:

It seems these recent papers focus less on the performance of the two methods of concurrency and more on the concerns related to implementing them. But this hybrid model is very complex so why would I want to implement it? Is it just to allow my programmers to write code the way they like and then be able to assemble it all at the end? I just don't see how this has any advantages in terms of a ease of development.

Does this hybrid approach really meet that "sweet-spot" described in figure 1? To me it seems more like it just makes a big bubble and covers all three ares instead.

Henry Wong:

Are Windows NT fibers substantially different from running some user-level thread package (cooperative) on a single kernel (pre-emptive) thread? (I assume one can create multiple fibers in each thread of a multithreaded process?)

It seems their goal is not performance....but: What is the overhead of one of those Fiber-to-continuation or continuation-to-fiber adaptors?

Jean-Sebastien Legare:

A disadvantage of stack ripping is that it makes debugging difficult, because the stack provides less information on the sequence of events that leads a task into a given state. Would this disadvantage also apply to systems that use code with automatic stack management that calls code with manual stack management ? In one sense, would that exclude hybrid systems from the "sweet spot" ?

Given the fact that many current operating systems use automatic stack management for most of their subcomponents, could we consider it better for a cooperative program (i.e. a program that uses cooperative task management) that needs to interact closely with the OS (through system calls for instance) to go with the flow of the operating systems and follow its model ? Could keeping the same model as the OS save all of the overhead induced by the adaptors presented in the paper ?

Anoop Karollil:

Isn't a fiber a thread with asynchronous I/O? Are fibers implemented in Linux too?

This maybe branching out and not quite relevant to the paper, but what are tail calls and how does manually optimizing them away lead to an untraceable stack?

Discussion Recap:

Since there was a lot of material to get through discussion primarily followed the slides, and was scattered throughout the presentation. The questions on the slides represent the few broad categories that students had asked about. We were able to cover most of the issues at some depth with the exception of tail-call, and speculative execution. Continuations were not explicitly discussed, though we did cover closures and coroutines. Students were primarily concerned about the performance overhead and complexity of the system. We discussed the authors' contributions in the context of the events/threads debate.

In class Buck brought up one important point from the paper not covered in the slides:
"Stack Ripping" represents a significant problem in the context of evolving software (ie software that is modified) using the event driven model. When adding code that blocks a continuation must be used to prevent the entire event system from blocking. Since this now mean that the calling function is returning early (ie without its I/O completed) every function above it on the call graph must also have a continuation. The system in the presented paper solves this problem by transparently switching away from the event model prior to any blocking I/O.