Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rutgers!dptg!att!cbnewsk!ech
From: ech@cbnewsk.ATT.COM (ned.horvath)
Newsgroups: comp.object
Subject: Re: Reentrant code
Message-ID: <1126@cbnewsk.ATT.COM>
Date: 3 Oct 89 19:11:59 GMT
References: <11242@eerie.acsu.Buffalo.EDU>
Organization: AT&T Bell Laboratories
Lines: 34

From article <11242@eerie.acsu.Buffalo.EDU>, by axaris@cs.buffalo.edu (Vassilios Axaris):
> I have recently read somewhere (most likely a magazine article) that object
> oriented code must be non reentrant. Is this statement true? For some reason,
> I do not believe it is, since code is shared by objects through inheritance.

In the classical sense of "reentrant," I can't think of any reason O-O code
can't be reentrant.  However, there are pitfalls, applicable to programming
in general, that are drawn into sharper focus because of the frequent
claims of increased reliability for O-O development techniques.

Item: global variables, whether they are called that, or "class variables,"
or by some other euphemism, remain a shared resource.  Accessing such
objects in a multitasking environment has to be carefully managed.

Item: objects frequently display an "external consistency" -- a collection
of implicit or explicit invariants -- which are temporarily suspended
during the execution of a particular method.  What this means is that
chaos can result if several methods for a particular object are executing
concurrently.  One doesn't even need multitasking to get into trouble:
methods which send messages to 'self' must take care to ensure that the
object has enough INTERNAL consistency for the invoked method.

This last source of problems is complicated by the use of polymorphism
in O-O schemes: when you send yourself a message, the method invoked
may be that of a subclass.  Meyer gives good advice here: the entry
requirements for an overridding method must be no more stringent than
those of the overridden method, and the exit guarantees have to be at
least as stringent -- i.e. you can't EXPECT more, but you have to
guarantee at least as much.

Bottom line: there's no substitute for careful design, particularly in
the use of shared objects.

=Ned Horvath=