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=