CS 736 Reviews - Spring 2016

Cooperative Task Management without Manual Stack Management
1. summary
Cooperative task management paper is the method which uses automatic stack management with event-driven concurrency, a management method to mitigate the complexity of manual stack management, and to get benefit of easy and secure concurrency implementation. With programming examples, it provides how to construct cooperative task management.

2. Problem
Concurrency issues are a difficult problem in the past because it is hard to reproduce, identify and remove. The event-driven programming model is considered as an alternative to mitigate concurrency issues while it needs managing stack management manually. The preemptive programming model has an advantage from the perspective of automatic stack management while it does not offer efficient concurrency control.

3. Contributions
The main contribution in this paper is to establish the cooperative task management and to give the model of it. There are conflicting property among stack management and concurrency policy. The event driven task management has to handle the stack management manually and provides easy use of concurrency while it is difficult to read and maintain. By the way, the multi-threaded programming uses automatic stack management, easy to use and program, while it needs synchronization and it is hard to know about real operation about concurrency. To remove detrimental property from each policy, the paper introduces mixing the existing programming style and extracting advantageous points.
The method to get merits upon both policies uses fibers, user-level package. There are a two fibers: mainfiber which schedules manual and automatic tasks, and secondary fiber which execute function automatically. To process work between mainfiber and second fiber, there are two calling adapter: manual stack code calling automatic stack code, and automatic stack code calling manual stack code.
It makes less race condition and the programming easy.

4. Evaluation
The paper does not include evaluation section.

5. Confusion
-> What makes the difference between manual calling automatic and automatic calling manual? Which one is prefer to implement?

1. Summary

This paper has taken the concept of cooperative event driven programming and multithreaded preemptive programming and introduced the design of a hybrid model. The authors aimed to work with cooperative task management while preserving the automatic stack management that makes a programming language structured.

2. Problem

There are event generators that generate events and the dispatcher then calls their respective handlers. Multithreaded programming has preemptive task management with its automatic stack management has better code readability but comes with its share of concurrency issues which have to be explicitly handled by synchronization primitives such as monitors, semaphores. Whereas, event-driven programming with its idea of cooperative task management has manual stack management in the event of I/O calls and that leads to stack ripping. The difficulty arises in code maintainability. Continuation gives the reference to the event-handler that encodes post-I/O completion task. The call stack will only provide the current stack and will have no information of the events from where the current event was ripped, in the event of debugging issues. Hence, the most desirable programming would comprise of automatic stack management and cooperative task management which is implemented in the Farsite by the authors.

3. Contributions
The prime contribution is to use adaptors to connect the two programming models - event-driven and multi-threaded. Fibers are implemented in the user space, as opposed to kernel threads and are efficient in context switching. Fibers are cooperatively scheduled unlike threads(preemptively scheduled). Multiple fibers can be scheduled on one thread with only one active fiber at a time. Adapter connects the threaded and event-driven programming by the two adapters: CFA and FCA. A single scheduler running on the MainFiber, manages both the stack and task. There is a separate fiber for automatic stack management and that yields to the MainFiber. The flow would look like this: func(with manual stack)-->blocking function (with automatic stack)-->CFA:separate fiber to run callee-->returns immediately-->blocking call completes-->return to main thread: caller's continuation. For the other case when automatic stack controlled function wants to call manual stack based function, a separate continuation is generated and runs on the MainFiber.

4. Evaluations
The motivation of the hybrid approach was to make programming easier and that can comprise of both the models. The authors have evaluated their design by deploying it Farsite, a distributed server less file system and UCoM, a wireless phone application. For that purpose, the hybrid adapters were implemented with a series of mechanically-generated macros. But there is no comparison of the hybrid model with a purely event-driven and a purely multithreaded task management models. To understand the overheads introduced by this hybrid model such as context switches, more performance workloads should have been used. They claimed to have avoided race conditions but there are no timeline graphs that compare a concurrent work with tracing the deadlock time.

5. Questions
Pinning pattern concept is not very clearly described.

Summary
The key idea conveyed in the paper is that one can choose the reasoning benefits of cooperative task management without sacrificing the readability and maintainability of automatic stack management. It points out pitfalls in both manual and automatic case. It exhibits adaptors that enable automatic stack management code and manual stack management code to interoperate in the same code base.

Problem
The term "event driven programming" conflates both cooperative task management and manual stack management. This prevents many people from considering using a readable automatic stack management coding style in conjunction with cooperative task management. Evolving code with manual stack management imposes cumbersome code restructuring burden of stack ripping. Evolving either style of code involves revisting the invariant logic due to changing concurrency assumptions. A hybrid approach presented in this paper adapts between code with automatic and with manual stack management, enabling cooperation among disparate programmers and software evolution of disparate code base.

Contribution
The hybrid approach with "wrappers" in place that enables the two code styles to coexist is the primary contribution of this paper. However, in my mind, explicitly stating the task management and stack management are two different problems is another contribution which programmers may not be clear about. One good feature about this new hybrid approach is that with adaptors in place each style of code is unaware of the other. The code integration in two styles such that fiber execution looks like a continuation to the event driven code and the continuation scheduler looks like any other fiber to the procedure oriented code.

Evaluation
Employed cooperative task management in two systems: Farsite, a distributed secure server-less filesystem running over desktops, and UCoM, a wireless phone application for hand held devices such as PDAs. The FarSite system code was initially written in event driven style (cooperative task management and manual stack management) and then over a period of two years it was extended to adopt the hybrid approach as discussed.
However, the actual goal as the name of the paper suggests was cooperative style task management without manual stack management , there still is manual task management, they are just providing a hand-shaking between the styles of coding.
Absolute evaluation of this idea is difficult as it is a concept which can be deployed by programmers. Subjectively, the hybrid approach it helped them solve concurrency problems, but the task of wrapping I/O functions was "tedious". This cost of building adaptor has not been discussed in detail.
One important note is that, cooperative task management avoids concurrency problems of locks only if tasks can complete without having to yield control to any other task. As mentioned in the paper it can be solved by following a definite design pattern, however, these specific design patterns can again make further code extensions difficult. In my opinion this design is too complex when compared to the benefits received.

Confusion
Is this idea deployed today?

1. Summary
This paper discusses system design on Windows to support event-driven programming style to handle concurrent tasks with blocking I/O operation. It reviews on different traditional approaches to this problem in terms of task management, namely preemptive task management and cooperative task management, and stack management, automatic stack management and manual stack management, and proposes a hybrid approach to handling concurrent tasks.
2. Problem
There are different approaches to handling concurrent tasks on I/O operations in terms of task management and stack management, when each hold benefits and troubles. For task management, using cooperative task management over preemptive task management has benefit that the code region where control is transferred is well defined, thus making it easier to debug and recover state after control is recovered, and the support for event-driven programming avoids various concurrency issues including data racing and deadlocks. For stack management, manual stack management shows explicit support for event-driven programming style, but causes stack ripping which reduces code readability and makes it hard to debug, especially when different functions are produced in different languages.
3. Contributions
The major contribution of this paper is the design of a hybrid approach that allows concurrent model of both multi-threading and event-driven models to co-exist in the system and allows them to connect using adaptors. In their notion threads are preemptive while fibers are cooperative. A scheduler schedules for tasks using both models and sits on a special MainFiber where any other fibers should yield back to. Function calls between tasks using different models can work in a uniform style when calling code can create a new fiber to accommodate the corresponding blocking or non-blocking I/O feature.
4. Evaluation
The design described in the paper has been implemented on Farsite, a distributed, secure, serverless file system running over desktops, and UCoM, a wireless phone application. Both systems have adapted both concurrent models over time. The authors describe how this management model support both models well, and avoid concurrency issues. The evaluation they are giving is pretty subjective, and the benefits might be shown more clear if they will compare this against alternative designs to achieve certain feature requirements.
5. Confusion
I am interested in more details about how debugging is complicated in the case of event-driven programming, especially in different language environments.

Summary
The key idea conveyed in the paper is that one can choose the reasoning benefits of cooperative task management without sacrificing the readability and maintainability of automatic stack management. It points out pitfalls in both manual and automatic case. It exhibits adaptors that enable automatic stack management code and manual stack management code to interoperate in the same code base.

Problem
The term "event driven programming" conflates both cooperative task management and manual stack management. This prevents many people from considering using a readable automatic stack management coding style in conjunction with cooperative task management. Evolving code with manual stack management imposes cumbersome code restructuring burden of stack ripping. Evolving either style of code involves revisting the invariant logic due to changing concurrency assumptions. A hybrid approach presented in this paper adapts between code with automatic and with manual stack management, enabling cooperation among disparate programmers and software evolution of disparate code base.

Contribution
The hybrid approach with "wrappers" in place that enables the two code styles to coexist is the primary contribution of this paper. However, in my mind, explicitly stating the task management and stack management are two different problems is another contribution which programmers may not be clear about. One good feature about this new hybrid approach is that with adaptors in place each style of code is unaware of the other. The code integration in two styles such that fiber execution looks like a continuation to the event driven code and the continuation scheduler looks like any other fiber to the procedure oriented code.

Evaluation
Employed cooperative task management in two systems: Farsite, a distributed secure server-less filesystem running over desktops, and UCoM, a wireless phone application for hand held devices such as PDAs. The FarSite system code was initially written in event driven style (cooperative task management and manual stack management) and then over a period of two years it was extended to adopt the hybrid approach as discussed.
However, the actual goal as the name of the paper suggests was cooperative style task management without manual stack management , there still is manual task management, they are just providing a hand-shaking between the styles of coding.
Absolute evaluation of this idea is difficult as it is a concept which can be deployed by programmers. Subjectively, the hybrid approach it helped them solve concurrency problems, but the task of wrapping I/O functions was "tedious". This cost of building adaptor has not been discussed in detail.
One important note is that, cooperative task management avoids concurrency problems of locks only if tasks can complete without having to yield control to any other task. As mentioned in the paper it can be solved by following a definite design pattern, however, these specific design patterns can again make further code extensions difficult. In my opinion this design is too complex when compared to the benefits received.

Confusion
Is this idea deployed today?

Summary
The key idea conveyed in the paper is that one can choose the reasoning benefits of cooperative task management without sacrificing the readability and maintainability of automatic stack management. It points out pitfalls in both manual and automatic case. It exhibits adaptors that enable automatic stack management code and manual stack management code to interoperate in the same code base.

Problem
The term "event driven programming" conflates both cooperative task management and manual stack management. This prevents many people from considering using a readable automatic stack management coding style in conjunction with cooperative task management. Evolving code with manual stack management imposes cumbersome code restructuring burden of stack ripping. Evolving either style of code involves revisting the invariant logic due to changing concurrency assumptions. A hybrid approach presented in this paper adapts between code with automatic and with manual stack management, enabling cooperation among disparate programmers and software evolution of disparate code base.

Contribution
The hybrid approach with "wrappers" in place that enables the two code styles to coexist is the primary contribution of this paper. However, in my mind, explicitly stating the task management and stack management are two different problems is another contribution which programmers may not be clear about. One good feature about this new hybrid approach is that with adaptors in place each style of code is unaware of the other. The code integration in two styles such that fiber execution looks like a continuation to the event driven code and the continuation scheduler looks like any other fiber to the procedure oriented code.

Evaluation
Employed cooperative task management in two systems: Farsite, a distributed secure server-less filesystem running over desktops, and UCoM, a wireless phone application for hand held devices such as PDAs. The FarSite system code was initially written in event driven style (cooperative task management and manual stack management) and then over a period of two years it was extended to adopt the hybrid approach as discussed.
However, the actual goal as the name of the paper suggests was cooperative style task management without manual stack management , there still is manual task management, they are just providing a hand-shaking between the styles of coding.
Absolute evaluation of this idea is difficult as it is a concept which can be deployed by programmers. Subjectively, the hybrid approach it helped them solve concurrency problems, but the task of wrapping I/O functions was "tedious". This cost of building adaptor has not been discussed in detail.
One important note is that, cooperative task management avoids concurrency problems of locks only if tasks can complete without having to yield control to any other task. As mentioned in the paper it can be solved by following a definite design pattern, however, these specific design patterns can again make further code extensions difficult. In my opinion this design is too complex when compared to the benefits received.

Confusion
Is this idea deployed today?

1. Summary
Cooperative Task management helps programmers reason about concurrency issues. This paper focuses on the issues of stack management in the context of cooperative task management. The event driven programming consists of cooperative task management along with manual stack management. The authors present a hybrid model which can can adapt between both manual and automatic stack management code, allowing the users write more readable automatic stack management code and making the software evolution faster for applications using cooperative task management.

2. Problem
Cooperative task management, based on event driven programming model, supports code with manual stack management for running scheduled events. This prevents developers from using readable automatic stack management coding style for task management. Also, evolving code with manual stack management requires cumbersome code restructuring, as the programmer has to rip the code manually into event handlers. The authors are trying to solve the problem by proposing a hybrid stack-management model.

3. Contributions
The authors first present pros and cons of both manual and automatic stack based techniques and present their idea of a hybrid based approach allowing both the techniques to interoperate in the same program code. The major issue with manual stack management is the loss of readability and the need to rip conceptual functions whenever the procedure blocks or waits on the event(which is syntactically invisible in automatic technique). While the advantage of manual being, every yield point is clearly visible in the code.
The authors present the abstraction of adaptors to connect code using the separate stack models. The scheduler, has a simple design and manages both manual and automatic stack code. Code written in either style can be call a function implementing the other side without being aware of its stack management discipline.

4. Evaluation
The authors have implemented this hybrid approach on Windows using threads and fibers which are scheduled preemptively and cooperatively respectively. They have employed hybrid-stack cooperative task management approach in two systems Farsite and UCoM by implementing hybrid-adaptors in each direction along with as series of mechanically-generated macros. They were able to address concurrency problems this approach of cooperative task management. However the authors do not present any experimental comparisons between performance of hybrid cooperative model against preemptive model for an application.

5. Confusion
Could you go over manual calling automatic case in class. Also explain the pinning pattern.

1.Summary
This paper argues that the terms “event driven” and “multi threaded” conflate several distinct issues such as a gain in reasoning about concurrency cannot be obtained without manual stack management and vice versa. This paper proposes a hybrid approach where one can choose the reasoning benefits of cooperative task management without sacrificing the readability and maintainability of automatic stack management associated with multithreaded programming.

2.Problem
Event-driven programming and multithreaded programming have their own advantages and disadvantages. Event-driven programs includes collections of non-preemptive and non-blocking tasks and hence are easy to reason. But they require manual stack management when they yield control to other tasks (such as I/O). Multithreaded programs offer automated stack management and can exploit concurrency in multi-cores environment. However, programmers have to preserve inter-task invariants of shared state among concurrent tasks using locks and similar mechanism that can pose difficult challenges of its own such as deadlocks and starvation. It is very difficult to debug such programs.

The main problem this paper points out is that the two approaches are not mutually exclusive contrary to the popular beliefs. These popular notions just conflate underlying distinct issues such as reasoning about concurrency vs manual stack management.

3.Contributions
The overall contribution of this paper is the logical separation of the distinct underlying issues that are conflated by the conventional terms “event-driven” vs “multi-threaded” programs. The authors separate the concept of cooperative task management in the event-driven approach from the issue of manual stack management and show that programmers can consider using a readable automatic-state management coding style in conjunction with cooperative task management.
The authors propose a hybrid model that enables both styles to coexist in the same code base, using adaptors to connect between them. It adapts between code with automatic and with manual stack management, enabling cooperation among disparate programmers and software evolution of disparate code bases.

4.Evaluation
The authors only perform qualitative evaluation of their approach with subjective arguments such as their overall positive experience with both systems. The authors do not present any cost vs benefit analysis along any dimension such as human time, performance, blocking time and throughput.

This paper does a nice job of illustrating the underlying concept of multithreaded vs event-driven programming. However, the hybrid approach proposed by the authors cannot be evaluated due to insufficient performance metrics.

5.Confusion
I did not quite understand the idea/mechanism of data partitioning to reduce degree of shared state. How exactly is the transference of references and pointers prevented? The paper simply argues that care must be taken to prevent it.
Also the concept of continuation is not very clear to me.

Summary:

The paper discusses two programming models multi-threaded and event-driven and propose a new hybrid model incorporating the benifits of both the models.
Automatic stack management along with cooperative event driven task management interoperate in the same codebase.

Problem:
The authors explain two types of programming styles, mult-threaded with automatic stack management and event-driven programming with manual stack management. Both of them have pitfalls which authors have tried to point out. Event driven programming is easy to use when being reasoned for concurrency, is suitable on uniprocessor systems. But it is difficult to read as the design uses event handlers. It also includes coding complexity and the programming involves manual stack management, debugging complexity increases also which inturn increases the maintainablity. Whereas multi-threaded model is good from multi-processor perspective and is easy to read and maintain. One needs sychronization techniques to handle concurrency. So it becomes necessary to include benfifts from both the design paradigms.

Contributions:
The key contribution of the paper is to present hybrid approach manual and automatic stack management.
Tasks are normally managed either by preemptive task management where-in execution of tasks can mix on uni-processors/overlap the multiprocessors. By cooperative task management where a task's code only yields control to other tasks at well-defined points during the execution.
Cooperative task management is normally achieved by creating a collection of event handlers which leads to programmer doing manual stack management. The preemptive model whereas is supported by automatic stack management where each task is a single procedure in the source language. In manual stack management, every yield point is explicitly visible in the code. However, in automatic stack management, the concurrency can be hidden and lead to serious issues in evolution. By use of adapters author build a hybrid system, they demonstrate it on Windows OS where threads are scheduled preemptively and fibers are scheduled cooperatively. MainFiber schedules both manual and automatic stack management code. The tasks which are on automatic stack always run on a secondary fiber and give back control to MainFiber on blocking.

Evaluation
The paper lacks proper evaluation as in comparison with contemporary models in performance. Although they did talk about Farsite and UCoM but there no description of the intricaties involved in it. Also adapters are programmatically generated but its validation is not described. Additonally how the existing applications can be modified /scaled to hybrid design is also not presented.

Confusion
How much of this work got relevance in the industry ?

1. Summary
This paper describes the advantages and disadvantages of two different programming paradigms - multithreaded programming and event-driven programming. While multithreaded programming exploits the benefits of automatic stack management, the event-driven model employs manual stack management. The authors propose a hybrid that exploits the best of both worlds; cooperative task scheduling with automatic stack management.

2. Problem
Multithreaded programming uses preemptive scheduling and exploits the benefits of automatic stack management. The code is more readable and maintainable. However managing concurrency correctly is a big challenge as applications could suffer from subtle race conditions, deadlocks, locking problems and other issues. Also, the programmer has little to no control over threads being scheduled. The problems worsen as software evolves. Event-driven programming paradigm on the other hand simplifies reasoning about concurrency but typically requires manual stack management which could lead to stack ripping while handling I/O. To solve this problem, the authors propose a novel solution that combines cooperative task scheduling with automatic stack management. The authors also introduce 'adapters' that allow interoperability between the two different styles of stack management.

3. Contributions
- The authors breakdown 5 different concepts: Task Management, Stack Management, I/O Management, Conflict Management and Data Partitioning. Though these are not entirely orthogonal with respect to each other, they could be effectively combined to develop a hybrid solution.
- Multiple fibers are scheduled on a thread preemptively while the fibers are scheduled cooperatively. The scheduler is run a special fiber called MainFiber and I/O operations are scheduled on others. Also, the scheduler simply switches between fibers and is unaware of the underlying style.
- Continuation to Fiber Adapter (CFA) can be used by code with manual stack management to call code with automatic stack management. The caller never blocks on I/O and the callee is executed on a new fiber. When I/O is completed, the scheduler executes the continuation to resume the caller.
- Fiber to Continuation Adapter (FCA) can be used by code with automatic stack management to call code with manual stack management. Here, the caller blocks and the callee schedules I/O and returns. When I/O completes, MainFiber executes the continuation to resume the adapter.

4. Evaluation
The authors implemented their design on two systems: Farsite (distributed serverless file system) and UCoM (wireless phone application). The authors claim that they had a positive experience with both these systems and that they were able to avoid many subtle concurrency issues by employing cooperative task management. However, none of the claims have been substantiated with evidence. It would have been nice to observe the impact of the overhead introduced by adapters and wrappers.

5. Confusion
More details about short-circuiting would be helpful.

1. Summary
This paper describes the differences and similarities between writing reactive code in an event-driven style and writing it in a threaded style. It describes programming-language mechanisms for writing systems code which combines both styles.

2. Problem
Much systems software is reactive in nature: it runs in reaction to some event (which typically occurs asynchronously) or creates an event to which other parts of the system must react. Such code is typically written in either a threaded style or an event-driven style. Code written in threaded style gives no clear indication of the points where asynchronous calls are made, which hides many concurrency problems actually in the code. Code written in event-driven style contrastingly indicates where it responds to an event, but requires manual stack manipulation, typically using continuation objects. In C-like languages, this complicates the code and debugging messages, since stack traces no longer describe well the control flow.

3. Contributions
This paper's primary contribution is C macros called adaptors that facilitate code calling other code written in the other style in a cooperative threading system. Code written in event-driven style typically uses continuation objects to indicate where an event should resume the code. The adaptor that facilitates calling such code from threaded code provides a continuation to return to the caller. Correspondingly, an adapter that facilitates calling threaded code from event-driven code also provides glue code for handling the continuation given by the event-driven code.

This paper also contributes a dynamic mechanism for detecting whether threaded code is aware of the yielding of control. It adds code to the methods that indicate an atomic block. This code increments and decrements a counter at the beginning and end of the block, respectively. If the function yields to another thread within that atomic section (most likely, under a method call or two), the program core dumps unless that counter is zero. Despite implementing this check dynamically, the authors nevertheless advocate for static checks, pointing out that "one could reasonably abuse an exception declaration mechanism to achieve this end."

4. Evaluation
This paper gives no quantitative evaluation of the work. The most evaluation they give is that all members of their programming team, who varied in which style they preferred, were pleased with the result. They did not even establish this via a survey (which might have been appropriate given their claims about readability and maintainability). Despite the extra code introduced by the adaptors, they do not compare the performance of programs that use these techniques to anything.

5. Confusion
To a programming languages guy like me, this reads a lot like a software engineering paper. Why is it considered to be in systems?
(This is not a complaint.)

Summsry:
The paper describes the issues in event driven programming and multi-threaded programming models and then describes an approach/hybrid solution that combines the best of both worlds i.e cooperative task management using automatic stack management and achieve a “sweet spot” in a way that entails minimum changes to the existing code.

Problem:
Event driven programming models are more suitable for uniprocessor systems and make the code less readable and maintainable in the presence of more and more threads (manual stack management issues). In the case of multithreaded programs, sharing and synchronization using locks, semaphores etc becomes cumbersome, reduces concurrency, could lead to invalid memory accesses as well if not programmed correctly and hence reproducing issues is very hard due to unexpected scheduling/timing of threads. Now to convert the existing legacy code written using the multi-threaded programming model to an even driven model would entail a lot of code changes. So, this paper proposes a hybrid solution that combines the event driven model approach along with automatic task management by building the necessary wrappers and making it transparent to the existing code.

Contributions:
Apart from describing the pros/cons of multi-threaded vs event driven programming models, automatic vs manual stack management, cooperative vs preemptive task management, I/O management and advantages of data partitioning in multi-threaded model, it describes the design and implementation of the hybrid approach that allows the co-existence of event-driven and multi-threaded programming using “adaptors” which is the primary focus of the paper and hence has been described in the next paragraph in detail. Threads are scheduled preemptively and fibers cooperatively, hence cooperative task management is typically achieved by scheduling multiple fibers on a single thread where the scheduler runs on the Main Fiber.

In the case of manual stack management code calling automatic stack management, where the calling code shouldn’t ideally block on I/O, the calling code creates a fiber for execution of the I/O and returns control back to the calling code using an adaptor and the caller resumes (as in manual stack management), but the newly created fiber blocks on I/O (as in automatic stack management). The fiber then returns only when the I/O is complete. In the case of automatic stack management calling manual stack management, where the calling code should ideally block on I/O, the calling code again invokes an adaptor and passes a continuation to the newly created fiber which executes a non-blocking I/O and returns control to the continuation/main fiber once I/O completes.
Thus programs can be developed that simply use adaptors to combine both the programming styles.

Evaluation:
The paper evaluates the hybrid model’s functioning in Farsite (which initially uses manual stack management) and UcoM (which initially uses automatic stack management), with macros used to implement adaptors. Since I believe evaluation was not the key focus of this paper and the intention of the paper was to combine two drastically different programming models with a high level of transparency, the authors do not provide details of benchmarks by comparing against the multi-threaded and event-driven styles individually and also about the additional cost/overhead of adding adaptors. But overall I think the impact of the paper lies in making existing code easier to manage (enhancing debugging abilities in multi-threaded code base by converting them to event-driven style) and also making future code easier to develop (manual stack management interacting with automatic stack management and vice versa).

Issues:
Could you please explain the optimization of tail events that was mentioned? I would like to know the impact of this work, Do they still co-exist or has the industry completely chosen event-driven style for easier management?

Summary
This paper addresses the concerns regarding the advantages and disadvantages of choosing event-driven programming over multi-threaded programming model and vice-versa. The authors have argued that task management and stack management are two mutually orthogonal separable concerns, which have been often conflated with each other in the context of event-driven programming. Finally, the authors have shown that using a hybrid approach, it is possible to achieve the best of the both event-driven and multi-threaded approach.

Problem           
In larger software projects, there is always a dilemma of choosing between event-driven and multithreaded programming model. While event-driven programming model makes it easier to avoid concurrency bugs and argue about program correctness, they often lead poorer readability and maintainability due to “stack ripping” of the code as the software evolves. The authors try to address this dilemma in the paper by suggesting that manual stack management is not a necessary requirement for event driven programming model.

Contribution
According to me, the following are the contributions of this paper:
(1) illustration of the fact that in the context of event-driven programming, task management and stack management are two orthogonal concepts, which have been often conflated with each other,
(2) elucidation of how cooperative task management can still be achieved while using automatic stack management, which was previously thought to be infeasible in the context of event-driven programming model,
(3) presentation of a hybrid approach using adaptors that enables both the programming models to co-exist in the same code-base without being aware of one another- thus providing best of the both worlds,
(4) demonstration of the exact execution semantics of procedure calls between code with manual stack management and code with automatic stack management,
(5) discussion of a new design pattern known as “Pinning Pattern” for cooperative task management that can be used to avoid locks, even for the tasks that yield for I/O.

Evaluation
The authors have evaluated their ideas of cooperative task management using hybrid adaptors for two real-world systems: Farsite and UCoM. Farsite is a distributed, secure, serverless file system running as a daemon process over desktops with Windows NT Operating System and UCoM is a wireless phone application for PDAs running Windows CE. Farsite uses fibers, while UCoM uses preemptive threads with condition variables to achieve a cooperating thread facility. However, much of their evaluation is subjective. The authors conclude that their experience has been positive and they were able to preempt many subtle concurrency problems by their hybrid approach.

As per my opinion, I felt that the evaluation was quite restrictive and limited, apart of being entirely subjective, as already mentioned. To better evaluate their system, the authors could have provided examples of concurrency problems that their hybrid approach was able to solve. Besides, there is not much mention of the performance impact of using adaptors and creating a separate fiber to process blocking I/O calls. In fact, as we read previously in the Scheduler Activation paper that user-level threads perform poorly for blocking I/O, I was more concerned with the performance numbers since the fibers are precisely user-level threads. However, such an evaluation was missing from the paper.

Confusion
What does tail call optimization mean and why does it lead to missing stacks in case of manual stack management?

1. Summary
Co-operative task management traditionally required Manual Stack Management and code ripping. This paper discusses a way to achieve the benefits of co-operative task management while retaining the ease of use of automatic stack management. Co-operati.e tsk management gives reasoning benefits, while automatic stack management enables readability and maintainability

2. Problem
The two prevalent task management models were 'multi-threaded' and 'co-operative'.
The Problems with threads -
Pre-emptive scheduling
Contention
Requires synchronization
Overheads make performance benefits harder
More complicated to reason about concurrency.
Problems with event-driven -
Manual Stack management
Much harder to code, due to stack ripping
Harder to debug
Single Logical task split into several language-level procedures
Multiprocessor parallelism not exploited
Both styles face issues, cause complications when software evolves.

3. Contributions
Hybrid approach.
'Threads' scheduled pre-emptively.
'Fibers' scheduled co-operatively. (no pre-emption)
Each thread has multiple Fibers
Combined scheduler runs on the 'Main Fiber'.
Adapters are used to connect between code styles, in a transparent manner.
In my opinion, the main contribution came from the logical separation of the concept of task management from the concept of stack management.

4. Evaluation
Implementation in this way was chosen to maintain legacy code base.
Hence, inter-operability was important.
Good point - combined scheduler manages both types.
There does not seem to be any data about relative performance of the two stack management styles.
Would have been nice to see some measurements, on performance.
However, the stated purpose is to make programming easier.
Further, event driven programming does not seem like a paradigm that could utilize multi-core / multi-processor systems well.

5. Confusion

1. Summary
This paper argues that both event-driven programming and multithreaded programming has their own advantages and disadvantages and shows how one can reason about concurrency using event driven programming without sacrificing the code readability and maintainability associated with multithreaded programming, by using cooperative task management with automatic stack management with the help of adaptors.

2. Problem
There has always been a debate in the programming community between using threads vs events for concurrent programming. Proponents of multi-threaded programming argue that threads are easy for programmers due to automated stack management and the developer needn’t worry about low-level scheduling details. Threads are good to exploit concurrency in multiprocessor environment. Opponents argue that incorrect locking may introduce deadlocks or starvation while fine-grained locking might bring down the performance and concurrency bugs are difficult to debug. Event-driven programming involves cooperative task management where a program is organized as a collection of non-preemptive and non-blocking event handlers which explicitly yield control to other tasks at well-defined points and hence is easy to reason about concurrency. Opponents of event-driven approach argue that it involves manual stack management where the code is ripped to make blocking handlers non-blocking which further becomes cumbersome as software evolves with complex code for eg: multiple I/Os within loops, thus making the code difficult to read. This approach is also inappropriate to exploit multiprocessor parallelism.

3. Contributions
i) The first contribution of the paper is arguing that a programmer can get the best of both the worlds - benefits of event-driven programming without cumbersome manual stack management. The authors separate out the concern in multi-threaded and event driven programming in terms of task management and stack management. Multithreaded programming involves preemptive task management with automated stack management whereas event driven programming involves cooperative task management with manual stack management. The authors identify that the sweet spot is to have cooperative task management with automatic stack management. ii) The authors propose a hybrid approach which enables procedures written in both styles to coexist using a novel concept of adaptors to connect between these two code styles. By scheduling multiple fibers which are not preemptable on a single thread that can be preempted, cooperative task management is achieved. The scheduler runs on a special fiber called MainFiber and schedules both type of code. iii) The key technique is when a code written in automatic stack management is executed which is expected to block for IO, an adaptor code runs the latter on another fiber and control is yield back to MainFiber when it blocks. When the I/O finishes, a continuation is executed and the new fiber is resumed as if it got unblocked from the I/O and proceeds to completion. Thus code written in either style can call each other. One of the key disadvantages of event-driven programming to me seems to be its ineffectiveness in not being able to utilize multiprocessor parallelism. Given this disadvantage, how this programming model was adopted by many is puzzling to me.

4. Evaluation
The authors perform a subjective evaluation of how it was a positive experience for them to employ cooperative task management in two systems - one has manual stack management and the other uses automated stack management. They claim that they were able to avoid subtle concurrency problems using their approach. It is difficult to reason about this claim. Were there any problems due to concurrency prior to switching to their approach? Why did the authors chose not to do any performance measurements? Evaluations answering the following questions would have been helpful: What is the cost of introducing adapters and what are its performance implications? What is the performance of the overall system compared to a pure event driven or a pure multithreaded approach?

5. Confusion
Concepts like closure and pinning pattern are not very clear to me. Is the adaptor automatically generated?

Summary : The authors in this paper propose the idea to effectively combine event-based programming with multithreaded programming to leverage the benefits of both the approaches. They aimed to achieve the ease of reasoning allowed for concurrency in even-driven model, and preserve readability and maintainability of code programmed in multithreaded style. They implemented a hybrid model that consisted of adaptors to aid in the co-existence of both approaches by interoperating in the same code base.

Problem : The authors took up the challenge to answer the highly debated question “what programming model to use”. Programmers were swamped with concurrency issues that were hard to reproduce, identify and eliminate. It was known that even-driven programming simplified these issues by reducing race conditions and deadlocks, but it required complex ways of manual stack management involving stack ripping and compiler involvement. In multithreaded programming it was difficult to handle race conditions and deadlocks as they had concurrency exhibited in a subtle way. Even though event-driven programming (where tasks yield control by returning to scheduler and run serially between yield points) reduced concurrency issues its utility was limited only to uniprocessors as it did not adapt well to multiprocessors or parallel execution. Software evolution further worsened the drawbacks of both the approaches. Hence the authors after careful understanding of the two approaches set out to implement a hybrid system (cooperative scheduling using automatic stack management) aimed at the “sweet spot”(structured programs) between the two approaches that would give the best of both the worlds.

Contributions : The authors after having carried out deep analysis of pros and cons of the automatic and manual stack managements express that each of the 5 concepts can be considered orthogonal for a better understanding. They then devise a hybrid approach that targeted the sweet spot in this hypothetical space: a] use adaptors to connect between two code styles, b] hence code in one style can include code in another style, c] threads are scheduled preemptively and fibers scheduled cooperatively with fibers acting also as event handlers, d] multiple fibers can exist in one thread, e] MainFiber has a scheduler that runs in it which is responsible to schedule both types of codes, f] code written in automatic stack management that expects t block for I/O on other fiber yield control to MainFiber when it blocks, g] compute-only functions can run on any fiber.
-Manual calling Automatic {Setup continuation objects(copy result and invoked original continuation) -> set up fibers -> switch to fiber -> Issue I/O -> no actually blocking but asynchronous I/O is used and yield back to main fiber}.
-Automatic calling Manual {setup special continuation(if we did actually switch fibers simply return) -> invoke event handlers -> return to main fiber -> resume fiber}
-Stack ripping : yield-points explicitly visible in code, static checking that leverages the compiler and checks for basic block that calls a yielding function must be tagged yield, if not warning is issued, an dynamic checking that uses counter at run time where each code that depends on atomicity starts with StartAtomic() and ends with EndAtomic().

Evaluations : The authors have evaluated their design by deploying it Farsite, a distributed severely file system and UCoM, a wireless phone application. In Farsite stacks represented states and pointer swapping aided in control transfer, whereas in UCoM condition variables for synchronization aided in scheduling. Locks were avoided by concepts such as resource pinning and data partitioning. I/O wrappers had been automated since it was a tedious task. I can indeed say that this was a very novel and sophisticated way of dealing with the combination of event-driven and threaded paradigms. The authors could also achieve their goal of having a successful hybrid design in place that got the best of both programming paradigms and could be deployed across various kinds of systems. Having said the above I also feel the authors still fall short to show the success of their claim by any empirical data which could have catered to time/space overheads of this hybrid system in comparison to the conventional ones, overhead due to continuation objects and adaptors and macros.

Confusion : i] Concept of closures? ii] Short circuiting? iii] This seems to be too complex, as every cross call needed an adaptor, to what extent was this approach commercialized or adopted by other systems? iv] How does context switch occur and its associated overhead?

Summary
The Paper tries to address the problem of event driven and Threading code styles by suggesting an hybrid approach which provides the benefits of automatic stack management and co-operative task management by using adaptors which allows calls between Manual and Auto stack management code.
Problem
For Concurrency there are 2 approaches. 1]Even-Driven 2]Multi-Threading. Even Driven approach avoids issues of race conditions and dead locks, but the manual stack management becomes cumbersome as the concurrency grows.In Multi-Threading Approach The synchronization mechanism becomes difficult when there are many threads running in parallel and there is global data shared among them(Handling large atomic operations). Also In Multi-Threading approach when we concept of fibers as in windows, if the called function yields on I/O , all the calling functions should change the semantics.So if the code has grown huge , change like this will affect calling semantics of many procedures. So the author provides a Hybrid approach which will give the advantages of automatic stack management as well as co-operative task management called the Sweet Spot.
Contributions
The Main Contribution of the paper is the hybrid approach enables the Co-exist of both event driven and threads(fibers) coding styles by using the concept of Adaptors which also helps in incorporating the legacy code . Adaptors handle situation
1] Manual Stack management code calling an Automatic stack management Code: In this situation the calling code never expects to block on I/O but the called procedure blocks on I/O. The Situation is handled by an Adaptor which creates a fibre and returns the execution to the caller. The caller can resume its operation. The fibre Created will return only when I/O is complete avoiding return when blocked for I/O, returning the value to the caller when complete.
2]Automatic calling Manual Stack management code. Here the Adaptor ensures the the execution of the caller of automatic stack management code resumes only when I/O is complete using the concept of fibre and shortCircuit . shortCircuit which is flag set when I/O is not complete. When is fibre resumed for execution the shortCircuit is checked to avoid return when blocked by I/O
Evaluation
Evaluation part is not detailed . The authors say they tested for 2 applications Farsite - Distributed File system which is an even driven style code changed to handle cooperative task management . and UCoM system that uses automatic stack management modified for hybrid approach. They mention the concept of fibre being used but at the end in evaluation the system picked didn’t have fibre support so they used threads with locks. Now with threads was the performance achieved which was expected is not even shown, the author himself mentions from the start of paper that using locks, CV to avoiding concurrency and deadlock issues is not easy when many threads present. So i don’t think the evaluation clearly represents the concept spread though out the paper
They evaluation just says that with both systems the experience was positive without any numbers or graphs on performance of the system with this hybrid approach. They say they used a design pattern called Pinning Pattern to pin resources in memory, the drawback being if used among dependent potentially yielding operations. Evaluation of this mechanism is not even given.
A more detailed evaluation of the performance of the system with and without the hybrid approach would have been great.
Summary
Please explain Short-Circuiting in detail

1. Summary
This paper combines the concurrency advantages of cooperative task management with the conveniences of automatic stack handling of preemptive approaches.
2. Problem
Cooperative task management allows easy reasoning about concurrency with fewer subtle issues and deadlock conditions. However this requires the programmers to manually shred the stack of all event based code and encapsulate any state that may be required by the responding event manager. This makes the code verbose and difficult to maintain as each function with blocking calls needs to be split into 2 or more functions. Standard preemptive task managers do not suffer from these faults but can be impacted by subtle race conditions. Hence a function may need to carefully check any shared state around a blocking call as it may have changed leading to future corruptions. Both these issues are exacerbated as a code base grows and may need to interpolate with code written with a different methodology
3. Contribution
The authors first disentangle the concepts of task, stack and I/O management and point out how design decisions in one sphere implicitly dictate them elsewhere. Event driven task scheduling leads to manual stack management and automatic stack management seems to be possible only with preemptive task schedulers. They then break down this assumption by writing a layer made up of adaptors that allow event driven/manual stack management code bases to interact with preemptive/automatic stack management functions in a transparent manner. This is accomplished by having one fiber responsible for scheduling both event driven and preemptive tasks. The preemptive tasks run in a different fiber as they may be blocked at which point they return control to main fiber. I/O is handled in an event based fashion without blocking and with control being handed back to the main fiber.
4. Evaluation
The authors implement a prototype on Farsite a distributed file system and UCoMa, an application for PDAs. These two systems offer the two extreme deployment scenarios with Farsite being primarily event driven and UCoMa being preemptive. The authors mechanically generate macros in either direction for varying combinations of argument and return types and number. The authors then comment that the experience was positive as they were able to avoid subtle race conditions. However, they do not lend any credence to this assumption. This could be solved by running a highly concurrent workload on both systems and tracing the time spent waiting for or being deadlocked over locks with the performance of the current system.
5. Confusion
I do not understand the need for pinning resources in memory especially since cooperative task management should have less need for locks?
I am not clear on debugging techniques required for event driven programming and the impact of optimizing the tail function calls.

Summary
The paper is about combining the best of two worlds : threaded and event-driven programming . The authors propose a hybrid approach that allows both programming paradigms to co-exist in a single application.
The problem
Preemptive multi-threading task management upholds easy readability and maintainability of code. However it entails complex synchronization for accessing shared data and is difficult to debug. Event-driven programming model can simplify concurrency issues by reducing opportunities for race conditions and deadlocks and explicitly identifying yield points. But the problem with this model is that the stack has to be manually managed. Here the control flow for a single conceptual task and its task specific state are broken across several language procedures (stack ripping), effectively discarding language scoping features. Moreover software evolution makes things even more cumbersome. Hence the authors were motivated to make both types of code work together in the face of software evolution.
Contribution
1.The paper identifies the “sweet spot “ that offers the ease of reasoning about concurrency issues of event driven task management and the automatic stack handling of preemptive task management.
2.It separates the notion of the oft conflated task management and stack management and explain their orthogonality.
3.The paper outlines a hybrid approach that uses adapters(wrappers) to connect between two code styles,ie, automatic and manual stack management. This enables project written in one style to incorporate legacy code written in others. Threads are scheduled preemptively while fibers are scheduled cooperatively. Multiple fibers are run on a single thread. The scheduler runs on a MainFiber (which schedules both type of code).By executing an “automatic” function on a secondary fiber, we can return to the main fiber to continue working . This entails neither blocking or stack ripping. All I/O calls must be asynchronous now , the MainFiber is continued immediately after scheduling the I/O request. Compute only functions can run on any fiber.
Evaluation
The paper shows the working of cooperative task management in two systems : Farsite and UcoM .The hybrid adapters are implemented with a series of mechanically-generated macros.
The paper grossly lacks in a proper evaluation of the performance of the system like an overhead comparison with purely event-driven and purely preemptive task management models. Moreover nothing is said on the actual concurrency achieved via this implementation.
I felt that the evaluation part is somewhat sketchy as they only provide a way cooperation between the two style of coding-automatic and manual stack. This falls short of their actual goal of merging automatic stack handling with an even-driven management.
Confusion
Why is the statement that returns control in a manual stack management simulated by a function call to a continuation procedure?

1. Summary: Via a novel combination of adaptors and use of cooperative threading facilities in Windows, the authors enable transparent transfer of control between standard procedurally-oreinted code with automatically managed stacks and event-oriented code written in a continuation-passing style.

2. Problem: Successfully exploiting OS support for concurrency is challenging; preemptive multitasking offloads the burden of scheduling to the OS, hopefully minimizing idle CPU time. However, given the possibility of preemption at any point of execution (or other threads acting in parallel on a multiprocessors system), preemptive multitasking requires careful partitioning of state between threads, the use of mutual exclusion constructs, or both. Event-driven programming provides a compromise between the trivial correctness of serial execution and the efficiency of preemptive multitasking, at the cost of requiring manual stack management. Event-driven programming decomposes programs into event handlers which execute atomically and voluntarily yield the CPU to an event scheduler upon completion or when blocking for I/O. The yielding procedure unwinds its stack, packages its state, and gives a continuation to the scheduler, which can be invoked to return control to the caller, or to resume computation upon completion of I/O. Since the process yields voluntarily, it is much easier to reason about concurrent access, and much of the need for sophisticated synchronization is obviated. However, event-oriented programs run into trouble when interacting with standard procedural code - while an event handler may be atomic, if it invokes a procedure that performs a blocking operation, this invariant will be violated. Conversely, due to the manual stack unwinding inherent in event-handling code, procedural programs generally cannot safely invoke event-handling code.

3. Contributions: In a manner analogous to the usage of stubs in RPC, the authors use special adaptors to enable the transparent transfer of control between code of either paradigm. The authors use Windows' "fibers", which enable cooperative multitasking within a thread. The primary fiber is an event scheduler, maintaining a working set of continuations which it can choose to schedule when the currently executing event handler yields. When an event handler in the main fiber needs to invoke code with an automatically managed stack, it creates and passes a continuation to a Manual to Automatic adapter, which starts the automatic procedure on a new fiber. This frees the main fiber to unwind its stack back to the scheduler and perform other actions, while the other fiber executes. Upon completion, the automatically managed stack returns to the adapter, which invokes the continuation. Conversely, when automatically managed code invokes manual code, it invokes an adapter which creates a continuation and passes control to the main fiber's event scheduler.

4. Evaluation: The authors' evaluation is subjective - they discuss their experiences developing a real-world system with this design pattern. They encapsulate the adaptors in a macro, and claim that they had a good development experience. I was a bit disappointed with the evaluation. While I appreciate that a true quantitative assessment probably requires a longitudinal study, which is infeasibly expensive, I would like any sort of detailed assessment. The work has a strong PL flavor; in many PL papers, evaluation is replaced by some sort of formal analysis of the programming model, such as a rigorous definition of the semantics and a sketch of a correctness proof. Such an analysis would be a boon for language implementors, and would be a unique intellectual contribution in itself.

5. Confusion I'm a curious how much work actually goes into continuation passing and stack management in C or C++, as it's not discussed in depth. In Lisp, for example, the compiler can automatically determine the appropriate scope for the closure, and will also optimize away unnecessary stack frames - this isn't the common case for C.

Summary
The paper discusses on the various aspects involved in using multithreaded or an event driven programming model with a focus on stack management. The two forms of stack management - manual and automatic, used in the above programming models respectively, are discussed thoroughly and a new hybrid approach is proposed that attempts to get the best of both worlds.

Problem
Multithreading programming uses automatic stack management and provide concurrency with the use of synchronization primitives. Though, it is simpler in use, they have hidden concurrency issues with some overhead of synchronization primitives. On the other hand, event driven programming involves using a manual stack management. Such stack management simplies maintaining concurrency as there are no synchronization primitives and hence no race conditions or deadlocks. But, it involves complex techniques of splitting task into multiple tasks and manually manage the stack. Hence, each of these programming models have disadvantages that the paper aims to resolve by introducing a new hybrid technique.

Contributions
a. The paper elaborates on the aspects like task management, stack management involved in a programming model with the dependencies involved for each. It further provides a detailed analysis for stack managements for both, event driven and multithreaded, programming models.
b. The paper proposes a new programming model which allows both styles to coexist in the same code base.
c. The new design was able to achieve the ease of concurrency as in event driven model while maintaining the readability and maintainability of the code.
d. The authors implemented a co-operative task management with the above hybrid approach on a Windows NT system and prove it's feasibility.
e. Function adaptors were used for automatic to manual and vice-versa calls. The detection of these two calls were facilitated by a dynamic or static checks of the code.

Evaluation
The authors come up with an implementation on Windows systems but give no idea on how good these systems work. Only the implementation specific difficulties/solutions and a discussion on how such design helps in using concurrency, are provided which does not help in understanding on how in reality this approach worked when compared to each of it's traditional approaches. The numerous factors like writing out function adaptors or using dynamic/static checks for auto/manual stack usage detection, could have been evaluated based on their work and time complexities respectively.

Confusion
Are the function adaptors written by programmers itself or the compiler generates those ?

1. Summary

In this paper, the authors demonstrate a way to combine task management and stack management to achieve a model that makes management easy and allows for simpler reasoning of concurrency issues. The paper focuses on the stack management problem in conventional system languages without elegant closures.

2. Problem

Multithreaded systems are not trivial as they require coordination for shared data using locks and are hard to debug because of data and timing dependencies. Alternative event driven programs are organised as collection of event handlers. Here, the control flow for a single conceptual and its task specific state are broken across several language procedures, discarding language scoping features.

3. Contribution

The paper initially describes the existing model paradigms and their drawbacks. They state that software evolution substantially magnifies the problem of function ripping. The author then proposes a new model that combines the advantages of the existing models. They aim to combine the cooperative task management model present in event driven programming by implementing automatic stack implementation. A hybrid approach using adapters is used to enable projects written in one style to incorporate legacy code written in others. The design of their approach in Windows operating system is explained. Threads are schedules preemptively and fibres are scheduled cooperatively. Multiple fibres are scheduled on a single thread. The scheduler runs on a special finer called MainFiber and schedules both manual and automatic stack management code. Code written with automatic stack management that expects to block, runs on a different finer and once done yields control back to MainFiber. Throughout the paper, the concepts were clearly demonstrated sample codes.

4. Evaluation

The authors employed the hybrid system on two systems : Farsite and UCoM. They simply state that their implementation experience is positive. However, not much evaluation is performed on the system. They do not show benchmarks for determining the performance improvements. Overheads that may have incurred in the hybrid approach due to the adapters are not studied. Overall, the paper does not demonstrate a proper evaluation of the new system proposed.

5. Confusion

1) The exact implementation of adapters is not clear.

1. Summary
In this paper, the authors highlight the differences, including pros and cons, of two main concurrent programming paradigms - event-driven and multithreaded programming. They emphasise how the traditional understanding unnecessarily associates concepts like stack management approaches with either of these. They distinguish between the concepts of task and stack management, present the pitfalls of manual and automatic stack management, and finally provide mechanisms (adapters) to allow both stack management approaches to co-exist.
2. Problem
Event-driven programming has been considered to be better for reasoning about concurrency. However, it is plagued by the fact that the programs written in this paradigm are hard to read and maintain. On the other hand, we have multithreaded programming where handling concurrency among multiple threads poses a big challenge; although the programs here are more readable and maintainable. The conventional wisdom suggests that the simplicity in reasoning afforded by event-driven programming cannot be achieved without handling complicated manual stack management. The authors challenge this notion and aim to achieve the best of both programming paradigms - ease of reasoning of event-driven approach and the readability/maintainability of multithreaded approach.
3. Contributions
One of the biggest contributions of this work is to clearly draw a line between the concepts of task management and stack management. Task management is mainly concerned with how multiple serial execution streams are scheduled to run to complete the desired task. However, stack management is more about the mechanism required to support the chosen task management model. They also present other concepts of I/O management, conflict management and data partitioning briefly as being orthogonal to the task management, which are many times confused as being associated with a specific task management model. The disadvantages of manual stack management are well explained, with detailed concrete examples. In conventional system languages, that do not have closures, manual stack management degrade the readability of the code. Further, the problem of stack ripping becomes worse with complicated softwares. These make the job programmer quite difficult which is not helped by impaired debugging capabilities. A key realization expounded in the paper is that cooperative task management is possible while still using automatic stack management. A system using fibres has been developed that allows procedures using either of the automatic or manual stack management to run. They also develop adapters, special glue logics, that allow both kinds of code to interoperate i.e. code with manual stack management can call code with automatic stack management, and vice-versa.
4. Evaluation
The proposed cooperative task management design was implemented in two systems - Farsite and UCoM. Farsite legacy code had manual stack management, and with the evolution of the software, automatic stack management code was incorporated. UCoM used condition variables for an implementation relying fully on automatic stack management. However, the authors simply state that the experience with both the projects was positive and they were able to avoid many subtle concurrency problems. There is no quantitative evaluation of any sort.
Another major issue in my opinion is that the paper does not discuss any criteria to help one make the choice between different stack management approaches, even in a hybrid design. Based on their experience, some more insight into how they made the choice between manual and automatic stack management for different parts of code would have been quite helpful in general and specifically to understand the importance of this work.
5. Confusion
Why did the authors chose to ignore the multi-processors so easily?
What are closures?
Authors mentioned the Pinning Pattern, which has not been explained well.

1. Summary
This paper talks about the problems involved in both event-driven (co-operative task management) & multi-threaded (automatic stack management) applications/systems. They propose a new hybrid approach that combines the advantages of both systems. The paper mainly focuses on the design aspects of this system and then talks briefly about their experience in implementing and using this system

2. Problem
Both event-driven and multi-threaded systems have flaws. Writing/Maintaining event-driven system is hard. You also need to handle the problem of stack ripping where you have to manually manage most of the features originally handled by the compiler. On the other hand multi-threaded programming use automatic stack management which makes programmer's job relatively easier. But Handling concurrency, synchronization problems for multi-threaded systems are also hard (you also need to search/check for all yield points) whereas event-driven application have a single execution stream.

3. Contributions
The paper first explains 5 main concepts relating to system design (task management, stack management, I/O management, Conflict management and Data partitioning) with the focus being on task and stack management. It then proposes a new design which uses both cooperative tasks (event-driven) & automatic stack management(multi-threaded programming). Such a system is easy to read/maintain and makes it easier to deal with concurrency issues. One of the things that I liked about the paper was that they considered the problem of software/ code evolution, this was the first time I have seen anyone talk about this as a legitimate hindrance. They decided to implement their whole idea on windows (using fibers which are user-threads):with a main fiber which handles scheduling, a secondary for tasks which can get blocked and yield to main (while avoiding blocking and stack ripping), and also each compute-only task can run on a separate fiber. They also talk about some of their implementation details like creating wrappers and adapters to make things less complex (manual calling automatic and vice-versa is done with adapters).

4. Evaluation
The implementation was done on two systems: Farsite (distributed, secure, server-less file system for desktops) and UcoM (a wireless phone application for hand-held devices). They claim that their experiences were positive and they were able to preempt many subtle concurrency problem. It would have been nice if they could have compared their new hybrid system with event-driven and multi-threaded systems for different applications, workloads (to further show that they achieved the sweet spot). I also think they should have spoken more about the amount of effort and overhead involved in creating/using adaptors, fibers etc.

5. Confusion
Isn't their idea of restarting loops (mentioned in last paragraph of the implementation experience section) if yielding occurred highly inefficient? Has this idea been further refined? Also what is the meaning of "closure"?

1. Summary
This paper begins with the description of two orthogonal programming models – multi-threading and event-driven. The authors go on to propose a novel approach as a result of which one could get best of both the aforementioned models by providing concurrency as advocated by the event-driven style and at the same time preserve the readability and maintainability of the code, which is normally a characteristic of multi-threading. The basis of the proposed approach involves the usage of adapters that enables the interoperation of automatic stack management and manual stack management.

2. Problem
As mentioned earlier, multi-threading code has the advantages of being readable and maintainable due to usage of preemptive task management along with automatic stack management. However, it is non-trivial to reason out concurrency in the multi-threading approach and often involves the usage of synchronization techniques. On the other hand, event-driven model involves usage of cooperative task management and manual stack management. This programming model involves modelling the cooperative tasks as event handlers that yield to the scheduler at well-defined points. Recent software evolution has made stack ripping even more cumbersome. The authors aim to propose a solution that is at the “sweet-spot” between both the orthogonal approaches.

3. Contribution
The main contribution of the proposed solution is that it is based on the best of the two programming models – multi-threading and event-driven. The authors come up with a hybrid approach that enables automatic stack management to co-exist and interoperate with manual stack management. This is achieved via the use of adapters. According to me, the major advantage of the proposed approach is that enables a project written in one style to incorporate legacy code written in another style. The authors go on to implement the proposed approach on Windows OS using threads that are scheduled preemptively and fibers that are cooperatively scheduled. The implementation consists of a scheduler that runs on a separate fiber known as MainFiber. Code written with automatic stack management is run in a separate fiber as it blocks on I/O. On an I/O operation this task yields back to the MainFiber, where the scheduler selects the next task to execute. However, an important point of consideration in the proposed solution is the overhead involved in the usage of adapters and wrappers. I feel that the authors did a commendable job of putting across their idea by using actual code snippets that made it easier to grasp their solution.

4. Evaluation
The authors implemented their proposed approach in two systems – Fairsite and UCoM. The authors go on to claim that the experience with both the systems have been positive and they were able to preempt many subtle concurrency problems by using cooperative task management. Apart from this, the authors have not carried out any extensive evaluation to validate the feasibility of their proposed approach. I feel that the authors could have compared the performance and flexibility of the hybrid programming style with its base programming styles. Another aspect that the authors missed out on was to quantify the amount of overheads experienced due to the usage of wrappers and adapters.

5. Confusion
What exactly happens when an I/O operation is completed but the MainFiber’s last scheduled task is still being executed? Does the continuation part of the initial task have to wait to be scheduled or can the current task be preempted?

1. Summary
This paper discusses the tradeoffs between the two models of programming, event driven and multithreaded. The debunk the myth related to event driven programming being tied to manual stack management and propose a system that achieves cooperative task management with automatic task management along with supporting legacy codes.

2. Problem
Cooperative Task Management achieves concurrency by yielding on IO. Traditionally, this has required complex manual stack management to create objects to save the current state of the function and the caller function to return to once IO is serviced and the entire task is completed. This model makes it easy to reason about concurrency but difficult to read and debug. Multithreaded Programming bypasses the issue of manual stack management and relies on preemptive task management to achieve concurrency. However, one has to deal with complex reasoning around locks and its associated pitfalls.

3. Contribution
There are three major contributions of this paper. Firstly, they establish that task management and stack management are two orthogonal concepts which do not have to go hand in hand. As a result, one can hit a sweet spot by choosing the benefits of a cooperative task management without sacrificing the readability and maintainability of automatic stack management. Secondly, they show that software evolution can exacerbate the cost of function ripping in manual stack management while can hide the potential for concurrency in automatic stack management. They discuss a way to deal with the later. Finally, they develop a system that supports cooperative task handling with automatic stack management. They make the system flexible enough to support legacy code. They do so by creating wrapper functions (adaptors) that handle the messy details when a function moves from an automatic managed state to manually managed state and vice versa. As a result, one can evolve their code with any style and use these adaptors to tie with any model. While moving from manually managed stack to automatically managed one, they create a new user thread so that this thread function can block separately. The wrapper code launches this function on a new thread and returns to the event scheduler. On the completion of the I/O appropriate continuation handler is notified. When moving from an automatically managed stack to manually managed one, the wrapper code sets up a special continuation function that would later resume the caller’s thread. They also have a mechanism to save computations on state validation (short circuiting).

4. Evaluation
The authors have not presented a detailed evaluation of their system. They talk about their experiences while working on two projects that implement this hybrid system. They suggested that the programmers in both the project picked up their preferred model of programming and that their system worked. However, some analysis of the potential overhead of the wrapper functions and the complexity involved would have helped gain a better understanding of the implementation of this system.

5. Questions
I did not understand the concept of pinning.

1. Summary
The authors came up with techniques which could pick the benefits of the cooperative task management scheduling with automatic stack management. This would help alleviate the effort of handling the stack manually for the developers, which involves stack management for blocking calls and other related operations.

2. Problem
Existing paradigm of stack management involved manual stack management while using cooperative task management. As a result, lot of effort was needed to handle the issues which arise due to this extra added complexity. Therefore biasing the developers to not adopt this method. Then, the programmers either adopted either event driven or multithreaded programming model (which gave automatic stack management benefits).

3. Contribution
The authors propose a hybrid technique which picks up from the best of both worlds - automatic stack management and cooperative task management.
It is desirable to adopt event driven programming model/cooperative task management, since then it becomes relatively easy to handle concurrency, gives a fine grained control and avoids unnecessary locks. They talk about adaptors which help bridge automatic and manual stack management. These adaptors automatically convert manual stack calls into automatic stack calls using macros (which can be thought of as analogous to how the marshalling or unmarshalling is done in RPC calls).
The manual stack, which is a blocking call can be converted to automatic stack management by running the manual stack on the Main-Fiber and the automatic stack on another Fiber. The manual stack ends leaving a function pointer with a ‘continuation’ which contains the further execution of the code once the blocking call returns from the I/O. The continuation can be thought of as a handler and mapping the I/O event with further code flow. Now issues arise when any one of the called function turns out to be yielding in a cascading call of functions which otherwise assumed to be atomic. This would require multiple multiple stack ripping. To handle such situations the authors proposed to predict the call nature either statically (by evaluating and then examining the nature of the calls) or dynamically. Overall, this design seems to be conceptually promising as it suggested a paradigm to merge legacy event driven code with modern multi threaded code in Microsoft.

4. Evaluation
Although the authors claim that the experience was positive in building such a system, they did not back it up with any quantitative results or profile the time costs for making such calls from the main thread to other fibers. They claim that the cost of context switch to a fiber is far less than that of a local procedure call, which was not very intuitive. Again, if they claim that the whole system was simple, they could have run a real life benchmark to establish the feasibility in a practical setting.

5. Confusion
I did not understand the concept hand-optimization of tail events and debugging events. Also, it was not clear to use the pinned resource in the context.

Summary:
The paper tries to make a point that the previously held notion that multithreaded programming and event-driven programming are opposite is false and proposes that programming decisions regarding task management and stack management are orthogonal. The paper also provides a capability for software written with disparate stack management policies can be used together while still respecting the global state invariants.

Problem:
The programmer’s are often confused that the choice of the programming style, whether multithreaded or event-driven, would directly result in the choice of the stack management, whether automatic or manual. The general notion is to bind cooperative task management approach to the manual stack management approach and the preemptive task management approach to automatic stack management approach with support of avoiding concurrency issues. This has often left programmer’s in two camps advocating one approach over the other.The paper tries to convince that this is a misconception and one can exploit the best of both worlds by treating task management and stack management as two orthogonal decisions.

Contributions:
1) The paper tries to make a clear distinction between terms such as task management, stack management, conflict management and I/O management. The authors believe these are mutually orthogonal to a large extent. This, to me, is the biggest contribution of this paper. By clearly understanding the definitions, one can easily see that the programming style decisions for each are essentially independent.
2) The paper cites some advantages and disadvantages of the manual and automatic stack management approaches. Automatic stack management is generally clean in terms of code readability but suffers from incompatibility of the semantics of caller and callee styles. Manual stack management is more cumbersome as the program stacks for each task needs to be saved in the heap during a jump in the control flow and checking the integrity of shared variables before resuming becomes crucial. The code thus generated is not easily readable. The authors also note that, with changes in the management structure of one of the functions, the application/task written with manual stack management needs changes to all functions that could potentially call the functions. With automatic stack management, it is much less intrusive.
3) The paper presents a hybrid approach where tasks written with the two different stack management styles can co-exist and work seamlessly while still maintaining global invariants. This is done with the help of glue code termed as adaptors which mimic the caller management in the callee. This approach has been demonstrated with user-thread (fibers) system in Windows NT.

Evaluation:
The objective of the paper was to clarify the confusion about the conflation of the ideas of task and stack management. The authors have gone on to prove coexistence of different stack management and task management styles by extending the existing cooperative task managed and manual stack managed application (Farsite) to automatic stack management code using the hybrid approach. Quantitative results as to which style is performance-wise better is not being discussed in the paper. The goal was not that too. Hence such data would have been irrelevant.

Confusion:
Why did event-driven programming get associated with manual stack management in the first place given the implementation is not concise and is generally time-consuming?

1. Summary
This paper re-examines “even-driven programming” and breaks it down into two separable design decisions - task management and stack management. They propose a hybrid system with glue code for using event-driven style code with multi-threaded style code, all of this under a co-operative task management scheme. This basically gives the best of both worlds.
2. Problem
Event driven programming and multi-threaded programming were the two popular styles to achieve concurrency between I/O and compute. Multi-threaded code was more readable, but the use of pre-emptive schedulers made it harder to maintain invariants on the shared state. It was easy to introduce deadlocks or races. Event driven programming was attractive in this sense because event handlers would never be pre-empted but yield. Reasoning about concurrency was simpler. However the method suffered from poor readability and maintainability as one needed to explicitly propagate state and fragment a task if a nested function could possibly post I/O events.
3. Contributions
The key insight the authors present is that event-driven programming can be thought of as a composition of two design concepts viz task management and stack management. Event driven code uses co-operative task management. However, it requires the programmer to manually propagate a function’s state on the heap, this is a concept the authors refer to as manual stack management. Multi-threaded programs on the other hand use the language’s automatic stack management support but opt for a pre-emptive scheduling scheme. The idea is to use the best of both design axes by pairing co-operative scheduling with a simpler automatic stack management.
At this point it appears to me that a mechanism like scheduler activations with multi-threaded code could possibly be the sweet spot, however their system is based on Windows Fibers so it may have different properties.
To support both styles of programming the authors propose a hybrid approach by providing glue code so functions from one style could invoke those of the other. The overall design would however use co-operative task scheduling. To main idea in moving from manual to automatic code styles is to create a new user thread so the thread-style function can block separately. The glue code launches the function on a new thread and returns to the event scheduler. When the I/O completes a wrapper function notifies the appropriate continuation handler. For an automatic to manual transition the glue codes sets up a special continuation function that would later resume the caller’s thread (Fiber). It also includes a special short-circuit flag which indicates if the callee never blocked on I/O. This could be used to avoid re-validating local state.
4. Evaluation
The authors present case studies on two projects that use the hybrid approach. Their main feedback was that they observed lesser instances of concurrency issues due to the co-operative scheduling approach in these systems. The evaluation is certainly a bit subjective. However, we could infer that programmers from both camps had the freedom to pick their preferred style and the system still worked. Some of the unanswered questions are the performance implications of the stub code used to interface the two styles and compilation overhead if any.
5. Confusion
Why not use scheduler activations and user threads? If Fibers have a similar upcall mechanism we can implement co-operative scheduling with user threads and avoid the even-driven style, are there other inherent advantages to this style of code?

1. Summary
The paper explores the reasons behind complexities involved “event-driven” multi programming paradigm and proposes a hybrid design which strives to attain the sweet spot which has the readability of a multithreaded program(achieved through automatic stack management) and concurrency issue free event-driven programming paradigm.

2. Problem
Multithreaded programs have lots of concurrency issues, which are many times difficult to even reproduce for debugging. Event driven programming is one alternative to avoid concurrency issues like race-conditions, but managing stacks in such a paradigm becomes a tedious task. Manual stack management affects code readability and requires extensive changes to the code as the software evolves. Automatic stack management, which improves readability, suffers from problems like hiding concurrency, non-yielding function calls, etc. when used for co-operative programming. The work is aimed at solving the problems involved in supporting automatic stack management for event driven programming.

3. Contribution
The paper proposes a hybrid approach which attains a sweetspot between multithreaded programming and event driven programming. The work lists the management issues like task and stack management, that needs to be managed when program is executed, and explores their relationship. The paper states that the programmers have conflated many of these management issues which may not be necessarily true. For example, event driven thread scheduling need not have manually managed stack and that they can co-exist. This is the sweetspot which the work has achieved.
Their work implements a dynamic yield check to make sure that the function yields on I/O wait and this ensures the co-operativeness and doesn’t let use game the scheduler. This technique is still affected by software evolution, however there are no extensive changes as in case of manually managed stacks and the changes are invisible and doesn’t affect the readability. Also, this methodology allows both styles of stack management to co-exist and enables seamless and transparent communication between them using adaptors. The paper explains their implementation using fibers in Windows NT and discusses scenarios of manual calling automatic and vice versa.

4. Evaluation
Evaluation presented in the paper is bare minimum where they just discuss about the learnings from their implementation in two different systems. The authors state that their experience had been positive with both the implementations and were able to remove the concurrency issue by using event driven thread management.Their aim was to shift the event-driven programming style to use automatic stack management technique and the paper discusses that extensively and the fact that it works in two systems supports their views. I think the absence of such evaluation actually makes sense since the work did not aim at improving any quantitative parameters like utilization, speedup,etc. Analyzing the implementation of the technique and pointing the inefficiencies and refining them could be done as a separate work and I think they are out of scope in such paradigm shifting works.

5. Doubts
Are fibers same as the user threads mentioned in Scheduler Activation paper?
What do the authors mean when they say building synchronous interfaces out of asynchronous ones and vice versa?

Summary
The paper explains the design of cooperative (event-driven) task management using automatic stack management for handling concurrent applications, which combines the reasoning advantages of cooperative event-driven task management with the benefits of code readability and maintainability of automatic stack management.

Problem
Conventional concurrent programming (multi-threaded programming) used preemptive task management and automatic stack management, which made its code readable and maintainable,but prevented the developer from obtaining a fine-grained control over concurrency aspects. On the other hand, cooperative task management, which involved yielding of a task's control at well defined points (events - such as task initiation, response on I/O, etc.) in the execution, required manual handling of the stack by using the callback mechanism. The cooperative tasks were organized as event handlers that yielded control to the event scheduler. This “stack ripping” required the programmer to manually handle procedural language features such as function scoping, automatic variables, control structures and (recovery of) debugging stack. Software evolution (function evolution from being compute only to being potentially yielding) made the function ripping problem even more cumbersome.

Contribution
The authors develop a hybrid approach that allowed both the procedural and event-driven programming styles to coexist. Adaptors served to connect these disparate styles by allowing a code written using one style to communicate with its counterpart in the other style. The authors implemented their approach by scheduling multiple fibers on a thread of the Windows OS, with the scheduler being run on the special fiber called MainFiber. The authors then extensively show how a function written in manual stack management can call a different function that uses automatic stack management, and vice versa. In both of these cases, it is observed that the adaptors and their wrapper routines (to pack / unpack arguments) are the key to making an execution transfer between the automatic stack management code region and the corresponding manual one, and vice versa. (I liked the attempt made by the authors here to explain these scenarios through actual code samples and execution flow diagrams.) The adaptors thus make each style unaware of the other, making code integration between the two styles easier. The authors also use data partitioning in their implementation for effective conflict management between the I/O threads and the state shared by cooperatively managed tasks. The Pinning design pattern was also implemented to provide manipulation of shared resources without yielding of tasks.

Evaluation
The authors mention that their co-operative task management system was implemented on Farsite (distributed, secure, serverless file system for desktops) and UcoM (a wireless phone application for handheld devices). However, no experimental analysis was carried out to measure the overall stack management overhead or the adaptor overhead. No performance comparison was made for these implementations against the counterparts of purely event-driven and/or purely procedure-oriented code. Another interesting study could be running these implementations against different types of workloads (e.g. compute vs IO intensive) . Also, as improving readability and maintainability of event-driven code was a key objective of this paper, the authors could have also provided a qualitative analysis of the same properties for their implementations.

Questions / Confusion
1. Short circuit branch handling

Summary

This paper explains the two widely used programming models and the baggage that they carry. Then they propose a hybrid model which has the advantages of both the worlds and show how code written in disparate styles can work with each other.

Problem

There are broadly two different programming models adapted by the community - event-driven programming and multi-threaded programming. Based on one's/team's understanding, either of these model is chosen for the project. However, both of these models have their pros and cons. Event-driven programming is easy to use when one is reasoning about concurrency and good for a single-processor system. But, code readability and maintenance is a major pain point. Additionally, with software evolution, event handler needs to be stack ripped to handle cases where now blocking is involved that was previously missing. On the other hand, multi-threaded programming is good from multi-processor perspective and is easy to read and maintain. It is difficult to reason about concurrency in multi-threaded programming model and one needs to use synchronization techniques to handle concurrency. Thus, it becomes important to find a sweet spot that has the advantages of both these worlds allowing the existence of disparate code bases simultaneously.

Contribution

Firstly, the authors clearly defines five key concepts (task management, stack management, I/O management, Conflict management and Data partitioning) that are extremely important from a system design's perspective. The paper revolves around just the first two concepts - task and stack management.
1. Task management - Tasks are normally managed either by preemptive task management where-in execution of tasks can interleave on uni-processors/overlap the multiprocessors, or by cooperative task management where a task's code only yields control to other tasks at well-defined points during the execution.
2. Stack management - Cooperative task management is normally achieved by ripping the code of any task into a collection of event handlers thus leading to manual stack management. On the other hand, preemptive model is supported by automatic stack management where each task is a single procedure in the source language. In manual stack management, every yield point is explicitly visible in the code at every level of the call graph. However, in automatic stack management, the concurrency can be hidden and lead to serious issues as software evolves.
Secondly, the authors propose a hybrid approach where they build a system using cooperative task management but using automatic stack management. This is achieved by the use of adapters. These adapters are code generated to reduce complexity for the developer. The authors explain the approach on Windows OS where threads are scheduled preemptively while fibers(user threads) are scheduled cooperatively(no preemption). Fibers run in context of threads. There is a special fiber called MainFiber that schedules both manual and automatic stack management code. Potentially locking automatic tasks always run on a secondary fiber and yield control back to MainFiber when it blocks. Thus, using adapters, the calling and resumption of the code is handled allowing both worlds to co-exist together.

Evaluation

The author don't provide any comprehensive evaluation other than discussing about their experience in building two systems - Farsite and UCoM. They find their experience to be positive in adapting the hybrid approach. However, they don't explain in detail the complexity involved with this approach and what is the cost of building the adapters. They just talk about implementing the adapters using mechanically-generated adapters. How do they verify the correctness of the adapters whether they do the right thing or not? Atleast they should have given the most easiest information about the cost associated with transferring the control between MainFiber and secondary Fiber. They don't even talk about scalability on multi-processor systems and how a pure multi-threaded application fares compared to the hybrid approach based application.

Confusion

Despite the pain points mentioned of the two models, industry uses both of these models with equal enthusiasm. I am eager to know the impact of this work.

Summary
The paper explains the concept of cooperative (event-driven) task management using automatic stack management for handling concurrent applications, which combines the reasoning advantages of cooperative event-driven task management with the benefits of code readability and maintainability of automatic stack management.

Problem
Conventional concurrent programming (multi-threaded programming) used preemptive task management and automatic stack management, which made its code readable and maintainable,but prevented the developer from obtaining a fine-grained control over concurrency aspects. On the other hand, cooperative task management, which involved yielding of a task's control at well defined points (events - such as task initiation, response on I/O, etc.) in the execution, required manual handling of the stack by using the callback mechanism. The cooperative tasks were organized as event handlers that yielded control to the event scheduler. This “stack ripping” required the programmer to manually handle procedural language features such as function scoping, automatic variables, control structures and (recovery of) debugging stack. Software evolution (function evolution from being compute only to being potentially yielding) made the function ripping problem even more cumbersome.

Contribution
The authors develop a hybrid approach that allowed both the procedural and event-driven programming styles to coexist. Adaptors served to connect these disparate styles by allowing a code written using one style to communicate with its counterpart in the other style. The authors implemented their approach by scheduling multiple fibers on a thread of the Windows OS, with the scheduler being run on the special fiber called MainFiber. The authors then extensively show how a function written in manual stack management can call a different function that uses automatic stack management, and vice versa. In both of these cases, it is observed that the adaptors and their wrapper routines (to pack / unpack arguments) are the key to making an execution transfer between the automatic stack management code region and the corresponding manual one, and vice versa. (I liked the attempt made by the authors here to explain these scenarios through actual code samples and execution flow diagrams.) The adaptors thus make each style unaware of the other, making code integration between the two styles easier. The authors also use data partitioning in their implementation for effective conflict management between the I/O threads and the state shared by cooperatively managed tasks. The Pinning design pattern was also implemented to provide manipulation of shared resources without yielding of tasks.

Evaluation
The authors mention that their co-operative task management system was implemented on Farsite (distributed, secure, serverless file system for desktops) and UcoM (a wireless phone application for handheld devices). However, no experimental analysis was carried out to measure the overall stack management overhead or the adaptor overhead. No performance comparison was made for these implementations against the counterparts of purely event-driven and/or purely procedure-oriented code. Another interesting study could be running these implementations against different types of workloads (e.g. compute vs IO intensive) . Also, as improving readability and maintainability of event-driven code was a key objective of this paper, the authors could have also provided a qualitative analysis of the same properties for their implementations.

Questions / Confusion
1. Short circuit branch handling

1. Summary: This paper is about combining the best of two worlds: threaded and event-driven programming to achieve the easy concurrency of the event-driven model while preserving the readability and maintainability of threaded code. The authors propose the idea of adapters to do this.
2. Problem: Event-driven programming offers advantages by reducing race conditions, deadlocks, and explicitly identifying yield points. But it is only good for uniprocessors since it does not allow concurrent execution in its true sense, and is difficult to read and maintain. Moreover, it uses complex stack management techniques that requires the programmers to rip a single task into multiple tasks, and manually do the stack management done by the compiler. Multithreaded programs, on the other hand, are easy to read and maintain, but introduce the necessity to explicitly maintain shared state by synchronization. Multi-threaded programs are also time-sensitive, and often have hidden concurrency. The authors say that event-driven and multi-threaded programming are often seen as opposite of each other, and neither model is the best. So, they find and implement a sweet spot between the two paradigms which would give the best of both worlds. Though the idea of task-management differs in the two programming models(serial v/s pre-emptive), these models need not use the different stack-management approaches(manual v/s automatic) they do now. They utilize this fact, and implement cooperative scheduling using automatic stack-management.
3. Contribution: To allow cooperative tasks to use automatic scheduling, the authors propose a solution which allows the manual stack functions to call automatic stack functions. They do this using adapters. This also enables both models to co-exist in the same code base and even allows either side to borrow legacy codes from the other side. They carry out their implementation on Windows system by using fibers and threads. They schedule multiple fibers on a single thread to achieve cooperative tasking. Code with manual stack code can call automatic stack code using CFA abstraction, while code with automatic stack management can call manual code using FCA abstraction. When a manual stack code calls an automatic stack code, since the caller doesn’t expect to block, the callee is run on a different fiber, and can thus block without affecting the callee. When an automatic stack code calls manual stack code, a special continuation is passed that allows the callee to be blocked. When unblocked, the continuation is executed which resumes the caller on the MainFiber.
4. Evaluation: It is not exactly clear from the beginning of the paper, as to what the authors aim to show. Their implementation provides a way for both the models to harmoniously co-exist in one code base, and call each other. Although, in the beginning it seemed they wanted to change the stack management technique used in event-driven programming. They also do not provide any evaluation of their implementation. How much overhead does this hybrid approach has compared to stand-alone multithreaded and event-driven codes? Also, I would be interested in knowing the actual concurrency they were able to exploit, by using this approach.
5. Confusion: what is a Closure? When event-driven programming is a single thread, why is it considered concurrent? I assume during an I/O, the process gets blocked, and a context switch takes place. So, the CPU doesn’t sit idle. Why to use event-handlers in this case?

1. Summary
The idea of the paper is to effectively combine multithreaded programming with event-based programming in order to achieve the best of both worlds. Cooperative task management is achieved by scheduling multiple fibers on a single thread. A new fiber is created when non-blocking manual stack managed function calls automatic stack managed function and alternatively, special adaptor and continuation is introduced to call manual stack managed function from blocking automatic stack managed code. Authors were successfully able to evaluate that concepts behind event-driven programming and threaded programming indeed overlap.
2. Problem
Majority of the programmers use either event-driven programming or multi-threaded programming. The problem with the former is that the code considered is difficult to read and maintain and is suitable only for uniprocessor based system while the latter faces difficulty in reasoning about concurrency with threads and this type of programming typically involves need for synchronization. Also it is suitable only for multiprocessor based system.
3. Contributions
Authors were able to achieve the ease of reasoning allowed for concurrency in the ‘event-driven’ model, while preserving the readability and maintainability of code associated with ‘multithreaded’ programming. They solved the hidden concurrency assumptions problem of automatic stack managed code by introducing dynamic check which was quick and easy to implement. Atomicity on shared state is not fix-grained and hence issue of conflict management was solved by introducing synchronization primitives. Explicit data partitioning made it easier to write and reason about invariants. By executing an “automatic” function on a secondary fiber, we can return to the main fiber to continue working thus eliminating blocking and stack ripping. With MainFiber scheduling manual and automatic task, all IO calls can be made asynchronous. To reduce the complexity for common developer in implementing cross communications between automatic and manual stack code, adaptors were introduced.
4. Evaluation
Hybrid approach was employed in Farsite; daemon process servicing file requests which was basically inspired as it’s codebase grew with the cost of maintaining it and UCoM; user-level client with UI and audio. Though UCoM didn’t actually used the abstraction of fiber due to its absence, it instead used preemptive threads and condition variables which may cause some instabilities like in multithreaded environment. Without any sufficient metrics like time it took to extend particular functionality with hybrid approach vs complex event driver programming or experimentation with uni/multi-processor, authors state that it preempted concurrency problems. With pinning design pattern, resources can be pinned directly onto memory thus avoiding need for locks and in the same case authors take further step to solve the dependency problem among potentially yielding operations. Authors also justify their use of user-level threads whose overhead, as they evaluate, is lesser than thrashing introduced by non-threaded programming model. Instead of over-explaining the obvious solution/problem in introduction and related work, authors should have shown concrete comparison between the 3 programming models.
5. Confusion
How are adaptors implemented and are they generated for each auto-manual call?

1. Summary
This work studies two orthogonal programming models- event-driven and multi-threaded in depth, and proposes a novel approach that merges the ease of reasoning for concurrency provided by event-driven programming model while preserving the readability and maintainability of a multi-threading model. In their hybrid approach, they have adapters and wrappers that help switching between automatic and manual stack management employing preemptive threads and cooperative fibers.
2. Problem
Multi-threaded programming model allows preemptive scheduling of tasks(interleave on uniprocessor or overlap on multiprocessor) and provides automatic stack management, thereby making it easy for programmers. But it requires cumbersome synchronization mechanisms for the shared states, hence difficult to debug, and achieve good performance(arguable). On the other hand, cooperative way through an event-driven model allows the program to be collection of event handlers, thus have single execution stream, event handlers yield as specific yield points, so no need of synchronization. But this requires manual stack management: rip the code for certain task into event handlers that run to completion without blocking (=> does not exploit multiprocessor parallelism)
3. Contributions
The authors came up with a novel hybrid approach to get the best of both worlds: automatic stack management with event-driven concurrency. This makes the code easier to read and understand while allowing one to reason over concurrency concepts with ease with automatic stack management and cooperative task management respectively. Program can be developed with the use of adapters to connect between the two code styles. It enabled some projects at Microsoft written in multi-threaded style to incorporate legacy code written in event-driven style. In this hybrid design, "threads" are scheduled preemptively while "fibers" are scheduled cooperatively, and multiple fibers on a single thread. MainFiber schedules both manual and automatic tasks. Code that expects to block on IO, runs on secondary fiber, and yields control back to MainFiber during blocking, while compute-only functions can run on any fiber. By executing an “automatic” function on a secondary fiber, we can return to the main fiber to continue working => no blocking and no stack ripping. Also, all I/O calls must be asynchronous to schedule the I/O request and then let the MainFiber continue.
While this approach seems viable, building adapters and wrappers seem tedious, rather making multi-threading efficient with solid concurrency controls seems more appealing.
4. Evaluation
They have implemented their design in two systems- Farsite- a distributed, secure, serverless file system running over desktops, and UCoM, a wireless phone application. The incorporation of this approach was positive(= adaptable) and they were able to preempt many subtle concurrency problems by using cooperative task management. Other than stating this they have not shown any other result or discussion. The aim of this paper was to show the coexistence of the two programming models, how flexible it is to evolve programs to have both threads and cooperative tasks, and eventually how efficient it becomes as a result of handling concurrency with the event-driven mode while exploiting maximum parallelism through multi-threading. They could have easily shown migrated existing workloads into this hybrid programming style to evaluate the flexibility, adaptability, overheads, resource utilization and efficiency towards achieving parallelism.
5. Confusion
Parts of the implementation where they pin resources and doing this in those with dependencies was obscure.

1.Summary:
This paper combines the best of worlds of thread based(preemptive) task management and event-based(cooperative) task management models. The authors have also defined the concept of adapters for co-existence of automatic and manual stack management code in the same code base.

2.Problem:
1) Co-operative task management is typically single threaded and consists of events to signal/access IO. It is non-preemptive in nature and thread continues execution with continuation object maintaining state for the IO event. This results in ripping of stacks, thereby forcing manual stack management.
2) In preemptive i.e, thread based task management, there are multiple threads where each thread blocks on IO and continues after IO completes. This does not require ripping of stacks and state is saved automatically. Here, synchronization of shared state across threads should be maintained by use of locks and other synchronization primitives.
3) The above can be avoided in event driven programming model, thus making it more efficient when reasoning about concurrency, where code between yields can be executed atomically. This provides motivation to develop cooperative task management with automatic stack management, which has the advantage of readability.

3.Contributions:
1) After analysis of pros and cons of different programming models and stack management models, the authors describe a hybrid approach where cooperative task management incorporates automatic stack management along with manual, providing interoperability between the two styles. 'Adapters' facilitate the same.
2) Multiple fibers are scheduled on a thread cooperatively. Scheduler is run on special fiber called main fiber and the IO operations on secondary fiber. Scheduler is unaware of the code style since it simply switches between fibers.
3) In manual stack management code(caller) calling automatic's code(callee), caller never blocks and callee is run on a different fiber and can block. When IO completes, continuation is executed by the scheduler to resume the caller. This uses Continuation to Fiber Adapter where the adapter handles details of the continuation and schedules blocking function on secondary fiber.
4) In automatic stack management code(caller) calling manual's code(callee), caller blocks and callee simply schedules IO and returns. This uses Fiber to Continuation Adapter, where the adapter calls manual stack code with a special continuation and yields to MainFiber. When IO completes, continuation is run on MainFiber, thus resuming the blocked adapter.

4.Evaluations:
The authors have implemented their design on Farsite, a distributed serverless file system and UCoM, a wireless phone application. Costs of manual stack management on Farsite was huge(no numbers available though), hence the hybrid approach was implemented on the same. Here, the states are represented as stacks and control is transferred through pointer swapping. Instead of Fibers, threads are used in UCoM and synchronization using condition variables is used for scheduling. Concepts of resource pinning and data partitioning have also been introduced to avoid locks. They say that the experience has been positive, but do not provide any evidence to support their claim. Profiling of the hybrid design and probable comparisons to unmodified cooperative/preemptive task management applications could have provided better insights.

5.Confusion:
What stack management model is there in today's event driven programming other than closures?
Could there be hybrid of task management models? If yes, how do they work?

1. Summary
This paper distinguishes the concept of task management and stack management, and then makes it possible to achieve both the reasoning benefits of cooperative task management and the readability and maintainability of automatic stack management by building a hybrid stack management model.

2. Problem
Traditionally, reasoning about concurrency is easier in event-driven programming than in multithreaded programming, but code written in the latter style is more readable and maintainable. Previous works did not realize these benefits come from different aspects and can be achieved at the same time.

3. Contributions
This paper makes a distinction between task management and stack management. Task management is about how multiple tasks are scheduled to run. The control of a task can be taken away at any time in preemptive task management, only after completion in serial task management, and at certain well-defined points in cooperative task management. Stack management is about how shared states are maintained between control yielding and resuming. Event-driven programming uses cooperative task management with manual stack management while threaded programming uses preemptive task management with automatic stack management.
The disadvantages of both stack management models are well-analized. Manual stack management requires a task to be organized as a series of event handlers by ripping it into parts at each yielding point, forcing the programmer to take care of a lot of language features which were normally managed by the compiler. Automatic stack management requires less change, but the problem is that these critical points are hidden in general function calls. This issue can be addressed by doing a static or dynamic check.
The authors also build a system with cooperative task management where code using manual and automatic stack management can interact with each other. The main idea is dedicating a cooperatively scheduled thread (“fiber”) for automatic stack management code and adapting the behavior of each kind with function stubs.

4. Evaluation
They implemented the proposed system for both Farsite on Windows NT and UCoM on Windows CE. No measurement data is provided and instead they share the experience. They simply claim many subtle concurrency problems are avoided, and mention a design pattern used to solve the problem of locks. It would be nice to see how much time is spent in the adapter.

5. Confusion
How is cooperative task management achieve on top of preemptive task management with condition variables? A thread should not be able to prevent itself being preempted by the scheduler.
How is the idea here compared to language provided closure and continuation?

1. Summary
There are two general styles of programming: “event-driven” vs “multi-threaded”, and the two styles often conflict. In this paper, the authors divorce the concepts of task and stack management, define their relation to each other, and express a paradigm in which the two can co-exist. They then present an implementation done on Microsoft Fibers.

2. Problem
There is a lot of argument over the two different programming styles named above and aso to which programming model is better. Done incorrectly, there can be bugs and concurrency issues that are difficult to remove. The paper does not argue which one is better, but rather advocates for a clearer breakdown of the two styles and suggests a hybrid approach to the problem.

3. Contributions
Essentially, they break programming down into five distinct concepts. The two of them that are most important are:
(1) Task management: a task is a control flow, and all tasks access a common state. Three general types: serial (one after another), preemptive (execution can overlap), and cooperative, where control is given up only at specific points.
(2) Stack management: a way to handle interrupts and switches.
(a) In manual handling, programmers organize programs as a collection of event handlers. To do this, the code has to be “ripped” apart for each I/O event, and there must be a “continuation” provided indicating where to resume the code. There is a substantial amount of manual stack management involved in this approach. The advantage is that each yield point is explicitly visible in the code, and potential concurrency issues can easily be detected.
(b) automatic handling relies on the support of the language itself. Switches are invisible, and the programmer does not need to consider how the stack is handled. On the downside, if a function is changed and its signature evolved for a new structure, these changes often go unhidden and can cause issues. Declaring concurrency assumptions explicitly can help, but they can be abused if written improperly.
The authors characterize the “multi-threaded” paradigm as being a preemptive-automatic model, while event-driven is cooperative-manual. They want to find the “sweet-spot” of a cooperative-automatic model. To that end, they develop a Microsoft fiber-based system that reconciles the two styles. Manual code goes onto the main fiber, and whenever automatic code is called, a subfiber is created and the automatic code is run. If/when the automatic code blocks fo I/O, the manual code resumes at the execution point until the automatic code returns. This is facilitated with an “adaptor” that handles calling and resumption of code. Ideally, with adaptors in place, the two types of code can effectively operate independently of each other.
To deal with concurrency issues, they created a pattern called the “pinning pattern” in which I/O operations can pin resources to memory. These resources are not exclusive, just held in memory until a loop can be executed atomically.

4. Evaluation
They deployed their task management style in two systems: Farsite (a distributed, serverless files system), and Ucom (a wireless phone application). Farsite was originally event-driven, and Ucom was exclusively automatic. The hybrid approach was implemented in both, and the authors declare that their experience was “positive”, which is a rather vague statement. One example evaluation they could've done is to take a problematic function that might incur a lot of concurrency errors under automatic handling, compare performance of manual, hybrid, and automatic respectively, and to calculate the overhead involved in the creation of fibers and deployment of adaptors.

5. Confusion
Is this idea really the first of its kind? What systems use this practice today?

1. Summary
In this paper, the authors talk about the differences between event-driven programming and multithreaded programming. They propose a hybrid approach that allows both programming paradigms to be used in a single application.
2. Problem
Prior to this paper, there had been a lot of discussions and debates over which programming paradigm is better: event-driven programming or multithreaded programming. Programmers either do one or the other, and their entire software can be in only one paradigm. Furthermore, each paradigm has its advantages and disadvantages. While event-driven programming can simplify concurrency and reduce the chances of concurrency issues, such as race conditions and deadlocks, it comes with the cost of manual stack management.
3. Contributions
As a result, looking at the differences between automatic stack management and manual stack management, the authors came up with a hybrid approach to allow code from both paradigms to be compatible with each other without a lot of work needed from programmers. The difference between the two management styles is that with automatic stack management, everything is procedure-oriented, and when a procedure performs an I/O operation, it blocks and waits until the job is done. In contrast, when using manual stack management, a procedure initiates an I/O operation and yields to give control back to the scheduler. Furthermore, the procedure mentions which procedure to call when the I/O operation is done. In the hybrid approach, the authors allow procedures of different stack management types to call each other. This is made possible through wrappers that capture the state when a procedure is called in another stack management style, which allows the switch and back from one stack management style to another. As a result, a code from one style can call another without even being aware that the other style exists.
When doing the transfers, it is important to understand what each style expects. When going from manual to automatic, the caller expects to never block on I/O, but the callee expects to always block on I/O. However, going the other way, automatic blocks on I/O but the manual code that is being called does not and tries to schedule an I/O and return. As a result, these features have to be caught to show the calling style what it expects to happen.
4. Evaluation
The authors did not really do an extensive evaluation of their system. They mostly just mentioned in which systems they implemented this approach: Farsite and UCoM. However, many evaluations are left out, such as performance, overhead of adaptors, complexity/overhead of compiler, etc.
In their related work section, however, they mention that the context-switch overhead between fibers is really low compared to a procedure call. This is obvious as fibers are user-level threads, which I believe they did not mention until this section. This changes everything because ULTs do block the entire process when doing I/O so it makes sense to want to yield and let others run.
5. Confusion
However, is that paradigm (cooperative + manual stack management) really needed when using KLTs? Specially, when a process/thread can be notified if an I/O operation is done through signals?

1. summary
The paper proposes a way to merge the advantages of cooperative task management and automatic stack management using a user-level non preemptive thread package on windows(fibers) ,a continuation object that bundles state and adapter functions that route control flow between different styles.
2. Problem
Cooperative task management with an event driven programming paradigm simplifies reasoning about concurrency but it requires manual stack management to handle I/O calls which leads to stack ripping. On the other hand, preemptive task management with multiple threads uses automatic stack management which leads to more maintainable code but also gives rise to subtle concurrency issues.These problems are further exacerbated by software evolution.The problem this paper tries to solve is to show that it is possible to get the best of cooperative task management and automatic stack management in one system.
3. Contributions
The paper provides definitions for fundamental ideas like task management, stack management,stack ripping and many more.They highlight that these concepts are not orthogonal and can be merged to create a new hybrid model. They propose a hybrid approach that enables manual and automatic stack management to coexist.Multiple fibers are scheduled in a single thread which can be preempted.The MainFiber schedules the manual and automatic tasks.Code with manual stack management can call code with automatic stack management using a CFA abstraction.Since the caller code expects to never block on I/O the callee code is executed on a new fiber.The caller resumes and manually unrolls its stack as soon as first burst of execution on the new fiber completes.The callee code can block if required.The opposite is possible using the FCA abstraction.The adapter that calls the manual stack management code is supplied with a special continuation that causes the caller to relinquish control of the MainFiber thus it gets blocked.When the I/O completes in the callee ,the special continuation is executed which resumes the caller on the MainFiber.
4. Evaluation
The proposed hybrid model is able to control subtle concurrency problems by using cooperative task management.The tedious task of wrapping I/O functions has been automated.Cooperative tasks that share resources but yield to perform I/O use the design pattern of pinning so that shared resources can be manipulated without yielding.A potentially yielding operation is run in a loop, after the operation completes if it ascertained that the operation yielded then the loop is started again.Since the entire loop executes without interruption, it is concluded that the loop executed atomically. The evaluation section could have expanded on issues like what is the overhead of having wrappers for I/O functions ? Do continuations cause a memory overhead relative to automatic stack management ? what is the complexity and time overhead of generating hybrid adaptors in the form of macros?
5. Confusion
Explain short circuiting and local state revalidation?
When a compute-only function evolves to potentially yielding how does this impact all functions along the path in the call graph?

1. Summary
The paper introduces multi-threaded and event-driven programming model and describes the design and implementation of a hybrid model which provides automatic stack management like in the multi-threaded model with co-operative task management like in the event driven model.

2. Problem
The paper describes two types of programming models: event-driven programming and multi-threaded programming. Each of the two models have their pros and cons. Event-driven model makes it easy to reason about concurrency, it uses co-operative task management technique and this approach is good for a uniprocessor system where tasks must interleave to avoid waiting on each other's I/O. The code in an event-driven model must be ripped into event handlers if the code is doing a blocking operation, this makes the code difficult to read. There is added coding complexity with languages that do not support closures as the programmer has to do substantial amount of stack management, debugging complexity increases as well because at the break point, call stack will provide information only about the current event handler and will provide no information of events from where the current event was ripped. But the primary drawback to event-driven programming is stack ripping which is caused as a software evolves and when a function is changed from non-blocking to to potentially yielding the programmer has to to change function along every path whose concurrency semantics will now be changed.
Code written with multi-threaded programming style is more readable and easier to maintain but this model makes it difficult to reason about concurrency as the thread scheduling is controlled by the OS scheduler and so it requires the need of some synchronization primitives to protect the critical areas.

3. Contributions
The main contribution of this work is to develop a hybrid approach where the automatic and manual stack management styles can co-exist by using adaptors to connect between them. The solution is implemented in Windows with preemptive threads and fibers, cooperative multitasking is achieved by running multiple fibers on a single thread, with only one given fiber active at any given time. A single scheduler is used to manage both the stack management code as the fiber package only supports switching from one fiber to another. The scheduler runs on MainFiber and the automatic stack management code which expects to block always runs on a separate fiber which yields to the MainFiber on the blocking call. When a function written with manual stack management calls a blocking function which is written with automatic stack management, the caller code creates a separate fiber to run the callee and returns as soon as the new fiber is setup. When the blocking call is done on other fiber it yields to the main thread and executes the caller's continuation. When a automatic stack controlled function wants to block by calling an automatic stack based function, the adaptor supplied to the caller creates a special continuation and blocks the caller by relinquishing control to the MainFiber. When the blocking call is done, the special continuation runs on the MainFiber and return to the fiber of the blocked adaptor which resumes the original function.

4. Evaluation
The paper presents a novel concept and discusses the design details of the solution. But there is no evaluation of the performance compared with languages which natively support event-driven programming model to asses the efficiency of their implementation. And it would have been good to see the compile time of programs using this hybrid abstraction as it looks like the compiler has to do a lot of extra work of adding stubs for adaptors.

5. Confusion
How are the adaptors inserted between different calls? User should not write the adaptors as the user does not know the type of stack management used by the caller and the callee, does the compiler do it?