Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!decwrl!megatest!djones From: djones@megatest.UUCP (Dave Jones) Newsgroups: comp.object Subject: Re: Reentrant code Message-ID: <8476@goofy.megatest.UUCP> Date: 3 Oct 89 02:33:34 GMT References: <11242@eerie.acsu.Buffalo.EDU> Organization: Megatest Corporation, San Jose, Ca Lines: 21 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. Either you read wrong or the article was wrong. Probably the latter. If anything, object-methods would tend to be more reentrant that the norm, because, except for memory management and statistical functions, such code tends to mediate its access to memory through a single "object-pointer". But, whether or not code is reentrant has nothing to do with its "object- orientedness". Think about it. There are two ways that code can be reentered: through recursion, and through a separate thread, as in interrupt-handling for example. Unless you are trying to write object-oriented code in FORTRAN :-), where creation of a procedure-activation obliterates any previous activation, both recursion and separate threads require only that access to data be restricted in such a way as to keep the "invariants" true except within "critical regions" in which neither interrupts nor recursion are allowed to happen. Whether or not the memory to which these invariants apply is referenced through a single object-pointer or not is irrelevant.