CMSC 838Y Paper Reviews

Skip down to paper 0: Przemyslaw Pardyak and Brian N. Bershad. Dynamic binding for an extensible system. In Proceedings of theUSENIX Symposium on Operating Systems Design and Implementation, pages 201-212, 1996. [ .html ]


Reviews for paper 0

Review from Prashant Lamba<plamba@wam.umd.edu> at Mon Feb 17 12:25:08 EST 2003:

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.

Review from Prashant Lamba<plamba@wam.umd.edu> at Mon Feb 17 12:27:10 EST 2003:

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.

Review from Yuan Yuan <yuanyuan@cs> at Mon Feb 17 22:17:42 EST 2003:

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. 


Review from Bryan Payne <bdpayne@cs> at Tue Feb 18 15:28:29 EST 2003:

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.

Review from Nikhil Swamy <nswamy@cs> at Wed Feb 19 20:25:44 EST 2003:

   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.

Review from piyush bhagat <piyushb@glue.umd.edu> at Thu Feb 20 00:21:17 EST 2003:

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.            

Review from Brian Krznarich bjkrz@cs at Thu Feb 20 07:50:44 EST 2003:

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.

Review from Polyvios Pratikakis <polyvios@cs> at Thu Feb 20 10:47:35 EST 2003:

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.

Review from Nathaniel Waisbrot <waisbrot@cs> at Thu Feb 20 10:56:54 EST 2003:

	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?

Review from Prashant Lamba<plamba@wam.umd.edu> at Thu Feb 20 12:02:21 EST 2003:

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.

Review from James Rose <rosejr@cs> at Thu Feb 20 12:25:07 EST 2003:

	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.

Review from Mujtaba Ali <mujtaba@bitsmart.com> at Thu Feb 20 12:31:13 EST 2003:

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.

Review from Jeff Odom <jodom@cs.umd.edu> at Tue Feb 25 03:10:00 EST 2003:

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


mwh@cs.umd.edu