PassiveVsActiveObjectModel

[passive.pdf]

Passive objects - entities which do not have their own threads and client threads migrate to these objects to do useful work. (@sa thread-migrate)

A passive object model provides enhanced performance and simplicity because it is more closely matched to the basic nature of microprocessors and the requirements of applications. It also provides more functionality by making the flow of control between objects a first-class abstraction which can be examined, manipulated, and used to carry information about the operation in progress.

Presented benefits:

1. Passive objects more naturally support synchronous object invocation, which is the common case.
2. Passive objects more closely model the nature of the underlying hardware.
3. The implementation of inter-object control transfer is simpler and faster with passive objects.
4. The explicit nature of inter-object control transfer makes more optimized implementations possible.
5. Passive objects can be smaller and more lightweight, because they involve less storage overhead.
6. Passive objects more accurately model the requirements of real-time systems.
7. Passive objects make accurate resource accounting easier.
8. Interruption of operations in progress is more easily implemented with passive objects.
9. Passive objects are easier to implement and manage in user code.
10. In a passive model, it is easier for personality servers to control the execution environment of their subjects.

Q&A

Q: "A passive model provides less protection, because clients must trust servers with their threads."
A: Migration of a thread to a server object does not necessarily grant the server any rights other than the right to temporarily execute in its scheduling context. With proper design, even this right can be revoked or transferred back into the client object in a way that fully maintains the protection of both the server and the client. Our work on supporting migrating threads on Mach [7] demonstrates how this can be done.

Q: "It is more difficult to program in a passive model, because all objects must handle internal synchronization issues." A: It is true that in an active object model, a simple object can be created requiring no internal synchronization by creating just one thread in the object. However, in a full microkernel implementation of passive objects, it often turns out to be extremely easy to achieve the same effect, such as by creating only one "activation record" on which incoming threads can run, or by maintaining a global lock acquired and released automatically on entry and exit from the object.

@todo biblio:

[7] Bryan Ford and Jay Lepreau. Evolving Mach 3.0 to use migrating threads. Technical Report UUCS-93-022, University of Utah, August 1993. A portion of this paper will appear in Proc. of the Winter 1994 USENIX Conference. [thread-migrate.pdf]

[1] Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37-55, February 1990. (contains general-purpose migrating threads model) [lrpc.pdf]