Paper on Dynamic Binding for an Extensible System explains the concepts of the SPIN extensible operating system. This operating system uses the concept of the event invocation mechanism to provide the feature of the extensibility. SPIN uses the events as its integration mechanism for the interaction between its components. According to this every procedure name in the system represents an event, every procedure invocation is raising of event. The system provides an event dispatcher for overseeing event-based communications. According to the paper it is the extension model and its implementation that determines the applicability and ineffectiveness. Although all the programming languages provide a number of approaches to extensibility but these are not able to provide support for multicast, transparent impositioning, filtering and conditional execution. This need outlines the need of SPIN extensible operating system. In SPIN the extensions are incorporated into the system through two steps. In first step the code is dynamically linked into the OS kernel and in second phase extensions registers the handlers with events .The concept of defining the events are well explained in the paper. In SPIN the modules communicate by procedure calls through interfaces. The concept of the guard and the handler are very well defined in the paper. According to the authors each handler can be associated with a set of guard that filter out the unwanted handle invocation. The concepts of evaluating guards (guards should be functional and free from side effects), ordering handlers (Multiple handlers on the same event should be executed in an order of their dependencies), passing arguments (dispatcher is responsible for the) and handling results are well explained in the paper. The paper also gives the information safety issues like Type checking, Access control and denial of the services also. Type Checking is described as checking arguments and returning values must be same. In the later part of the paper it describes the Implementation and performance of the system. The result of the performance measurements demonstrates that event processing overhead is small in both absolute and relative cases.
Paper on Dynamic Binding for an Extensible System explains the concepts of the SPIN extensible operating system. This operating system uses the concept of the event invocation mechanism to provide the feature of the extensibility. SPIN uses the events as its integration mechanism for the interaction between its components. According to this every procedure name in the system represents an event, every procedure invocation is raising of event. The system provides an event dispatcher for overseeing event-based communications. According to the paper it is the extension model and its implementation that determines the applicability and ineffectiveness. Although all the programming languages provide a number of approaches to extensibility but these are not able to provide support for multicast, transparent impositioning, filtering and conditional execution. This need outlines the need of SPIN extensible operating system. In SPIN the extensions are incorporated into the system through two steps. In first step the code is dynamically linked into the OS kernel and in second phase extensions registers the handlers with events .The concept of defining the events are well explained in the paper. In SPIN the modules communicate by procedure calls through interfaces. The concept of the guard and the handler are very well defined in the paper. According to the authors each handler can be associated with a set of guard that filter out the unwanted handle invocation. The concepts of evaluating guards (guards should be functional and free from side effects), ordering handlers (Multiple handlers on the same event should be executed in an order of their dependencies), passing arguments (dispatcher is responsible for the) and handling results are well explained in the paper. The paper also gives the information safety issues like Type checking, Access control and denial of the services also. Type Checking is described as checking arguments and returning values must be same. In the later part of the paper it describes the Implementation and performance of the system. The result of the performance measurements demonstrates that event processing overhead is small in both absolute and relative cases.
This paper takes one step further into SPIN operating system by looking into issues about events. Events are much like procedures with extended procedure call semantics. By using event invocation, SPIN is able to dynamically bind extensions into executing code and communications between components are down to the level of procedure call. Handlers are procedures executing in response to events and can be added and removed from events dynamically. Guards associated with events and are used to filter out unwanted handler invocation. To address safety problem, authors provide several protection mechanisms. As routine, type checking ensures type safety when installing handlers and guards. Access control mechanisms manage the accessibility of events. But with the expansion of extensible system, is there problem about the proper management and dynamically updating of these access control mechanisms? In the end, Authors provide us positive confirmation of event-based mechanisms by showing the result of performance.
This paper went in to a fair ammount of detail on the event system used in SPIN. The system appears to be well thought out and includes support for most of the mechanisms that one could need including support for multiple handlers and guards. In addition, there was a fair ammount of discussion on access control for the event system (to some degree, this discussion addresses my security concerns mentioned in my last review, but some still remain as well). It was nice to see this, as well as the Denial of Service discussion, included in a paper from 1996. I was left with a mixed impression of the event system. On one hand, it appears to have a clean design. However, I feel that it could quickly become complicated when used with complex systems. For example, keeping track of the order that handlers are called could quickly become cumbersome in a larger system.
This paper by Pardyak & Barshad elaborates on some of the details of the event-based extension model used by SPIN. Some space is devoted to explicating some of the concepts laid out in the previous paper by Barshad et al. The main content of the paper lies in the some of the details with regard to the safety issues of dynamic extensions. The access control model is based on the notion of an authority module defined ato be the default handler. The model includes a password protection scheme, which although not sophisticated, basically allows for an arbitrary degree of access control. In addition, an asynchronous dispatcher combined with a declarative model that permits preemption or termination, accounts for rogue extensions that run for too long. The advice from the authors about vigilance and paranoia when designing these extensions seems appropriate. The results documented show primarily the performance of the dispatcher w.r.t the number of handlers installed. The deficit in the previous paper which leaves the reader curious about scalability and end-to-end effects is addressed by the presentation of the performance of SPIN on an X11 app. While it appears as though this performance is acceptable, more information about the structure of the handlers and the extent of the dependencies/hierarchies between each these handlers would likely have been more illuminating.
The paper presents Spin as an extensible operating system, which uses dynamic binding in a flexible transparent safe and efficient way. I think these four properties should be the basic requirement for an extensible system allowing dynamic binding. Spin allows applications to add remove or augment old code at execution time. Spin implements this mechanism in a completely different way, which is why it is called an event-based system. The concept of events is very useful as we can change the relationship between the code components just by changing the set of handlers associated with an event. Events are defined in the interfaces to which extensions get linked. After this the extensions can install handlers on the events they export. In the other part of the paper the authors have presented the design implementation and performance of events in SPIN operating system. The design aspect of extensibility is explained through handlers .The paper also discusses safety issues. For safety Spin uses some basic mechanisms like type checking and access control applied to handler specification and governance of events. I think these measures are not enough for safety. Finally the paper discusses about the performance and implementation issues of the event services. The paper performed an extensive experiment measuring the overheads and suggested some measures for good performance like tight coupling of the dispatcher , runtime code generation etc.
This paper is mostly an extention to the previous paper on SPIN. It goes into somewhat more detail implementation , performance, and scaling for event handling and guards. Filters are mentioned- handlers which can take arguements by reference and modify them for future guards and the final procedure called. Ither than filters guards are required to be free from side effects- defined by the keyword FUNCTIONAL and checked by the compiler. Solutions to the problem of 'Runaway' handlers are discussed- including the expensive solution of spawning multiple threads so that a single handler can't freeze the system, and the use of EPHEMORAL handlers which can at any point be halted on a timeout without leaving the system in an unsafe state. Also, safety is somewhat discussed, including typechecking of handlers during instalation, and the notion of an Authoritative default handler which grants or denies permision for the instalation of new handlers. Their conclusion on performance and scaling is that performance is generally good and that the speed of an event scales linearly with the number of handlers. It's noteable that the addition of new handlers is O(n^2), though generally a fair assumption that the proportionally few events that have more than one handler (which behave as a function call) will still have a relatively small number of handlers.
In this paper a more in-detail view of the SPIN operating system is presented, regarding it's use of events. SPIN is written in Modula-3, a language that uses modules which interact through well-defined interfaces. Therefore, it uses the same mechanism to implement it's extensibility. All procedures exported by a module, are considered possible event handlers, and all call sites are considered events. SPIN utilizes dynamic linking techniques so that events can be linked to various event handlers, not necessarily constant through time (re-linking). To assert safety in such a dynamic environment, it uses the language features of Modula-3, which generates typed signatures of exported procedures for each interface. During linking (adding or altering of an event handler) the types of the event and the handler are checked. Event handlers can be guarded with expressions, and get executed only if the guard evaluates to true. Also, this paper describes the authorization mechanisms used to assert that only approved and wanted modules get inserted into the operating system. SPIN uses several authorization mechanisms to handle the "privileges" of modules, such as signing or passwords. Moreover, the issue of malicious code that could cause denial of service to other programs is handled using the notion of "ephemeral" handlers, which can be stopped after some time. Finally, measurements are presented and the efficiency and performance of the system is discussed. Overall, this paper presents many interesting ideas, such as dynamic event-handler linking without compromising safety, and handling security issues that arise from the system's extensibility. One could expect more detail in the description of the dynamic linker that integrates new modules/handlers into the operating system, or at least references to corresponding techinical reports.
The "Extensibility, Safety and Performance..." paper was a general overview of SPIN. This is a more detailed description of how SPIN's extensions work. Besides the simple events and event handlers, SPIN also has guard functions which control whether or not a handler is passed an event, and filters which modify an event by changing its arguments. There's also support for running event handlers in their own thread and for ensuring that handlers return in some bounded about of time. I was surprised that authority over modules was so simplistic. I was expecting authority over a module to rest with whichever module installed it. A module could always raise an event delegating its authority to some other module, but that still leaves it up to a module to determine who it will delegate its authority to. This was still a fairly high-level description of SPIN's behavior, so it was sometimes sparse on details. For example, what determines how long an EPHEMERAL handler can execute?
Paper on Dynamic Binding for an Extensible System explains the concepts of the SPIN extensible operating system. This operating system uses the concept of the event invocation mechanism to provide the feature of the extensibility. SPIN uses the events as its integration mechanism for the interaction between its components. According to this every procedure name in the system represents an event, every procedure invocation is raising of event. The system provides an event dispatcher for overseeing event-based communications. According to the paper it is the extension model and its implementation that determines the applicability and ineffectiveness. Although all the programming languages provide a number of approaches to extensibility but these are not able to provide support for multicast, transparent impositioning, filtering and conditional execution. This need outlines the need of SPIN extensible operating system. In SPIN the extensions are incorporated into the system through two steps. In first step the code is dynamically linked into the OS kernel and in second phase extensions registers the handlers with events .The concept of defining the events are well explained in the paper. In SPIN the modules communicate by procedure calls through interfaces. The concept of the guard and the handler are very well defined in the paper. According to the authors each handler can be associated with a set of guard that filter out the unwanted handle invocation. The concepts of evaluating guards (guards should be functional and free from side effects), ordering handlers (Multiple handlers on the same event should be executed in an order of their dependencies), passing arguments (dispatcher is responsible for the) and handling results are well explained in the paper. The paper also gives the information safety issues like Type checking, Access control and denial of the services also. Type Checking is described as checking arguments and returning values must be same. In the later part of the paper it describes the Implementation and performance of the system. The result of the performance measurements demonstrates that event-processing overhead is small in both absolute and relative cases.
Much of the content of this paper was addressed by the previous one, but there were several techniques that I had never seen used before. One is the way that the compiler verifies that guards are free of side-effects in order to allow certain optimizations. Another interesting analysis was the way that ephemeral handlers are dealt with. So far, I find the SPIN operating system very interesting because it applies language technologies in innovative ways to make a better operating system.
The SPIN extensibility model is described in detail here. Based primarily on an event-based structure (Publish-Subscribe pattern), the SPIN model adds some interesting features to allow for granularity, access control, and protection. These features are guards, authorization procedures, and asynchronous/time-limited execution, respectively. I feel the SPIN extensibility model had noble intentions, but the authors of SPIN tried to accomplish too much, and now the model is over-complicated. This is evident with the inclusion of filters, return handlers, and authorization procedures to SPIN. I believe the complication is the result of an almost religious focus on performance.
This paper does not so much introduce major new ideas as it does further explain the event mechanism behind SPIN. In brief, a SPIN event is a multicast procedure call with an optional predicate to control event reception. Much verbage was used to expound upon the previous statement (four pages in fact), yet the idea seems simple enough. On the other hand, side-effects and their role in event ordering and guard (predicate) evaluation need better treatment. The authors claim that all guard statement be purely functional (no side effects). To ensure, this, they automatically make copies of all arguments marked as references, and then set the reference arguments to point to the copies. This seems unnecessary and wasteful - it would seem that a type analysis should be able to determine if any of the reference parameters had been modified in a guard. Secondly, the utility of EPHEMERAL event handlers seems questionable. In theory, it seems a good idea to be able to mark event handlers as "safe to terminate." In practice it seems this would not happen often - there is no inherent advantage to the extension writer. Lastly, the benchmarks provided are wanting for an external frame of reference. The numbers provided only give absolute times - they do not compare to other operating systems (unlike the original SPIN paper, which compared against OSF/1 and Mach). Even the original SPIN numbers may not be compatible - the version numbers of SPIN are greatly different (1.26 in this paper vs. 0.4 in Bershad95). It is questionable if this paper introduces enough new material; it may have been better suited as a section or appendix to the original SPIN paper.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh