axaris@cs.buffalo.edu (Vassilios Axaris) (10/02/89)
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. But I want to be sure... Thanks, Vassilios E. Axaris
preston@titan.rice.edu (Preston Briggs) (10/03/89)
>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, >Vassilios E. Axaris Sounds wrongs to me. Perhaps someone's particular implementation has this restriction, but most don't. It certainly isn't a requirement specific to object oriented code. Preston Briggs
mnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (10/03/89)
In article <1857@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >>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, > >Sounds wrongs to me. Perhaps someone's particular implementation >has this restriction, but most don't. It certainly isn't a requirement >specific to object oriented code. Seems wrong to me also. I thought that object oriented code SHOULD be re-entrant. This is because the code may be executed for multiple instances of a class or sub class. Or am I blowing smoke? ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
Piersol@apple.com (Kurt Piersol) (10/03/89)
In article <11242@eerie.acsu.Buffalo.EDU> axaris@cs.buffalo.edu (Vassilios Axaris) writes: > 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. > But I want to be sure... On the contrary, object-oriented code is in general highly reentrant. Since the same code may be shared by many instances of an object class, each with a different state, the code must be reentrant for the whole scheme to work. However, a given object is often not reentrant. That is to say, one generally doesn't expect context-free operations of an individual instance. Since one of the purposes of an object is to store state information on which messages can operate, one must carefully write a class if instances are to be 'reentrant'. Generally, this involves some encapsulation scheme, where the outer object appears to be reentrant because all of its messages send further messages to an encapsulated object. The encapsulated object must be passed to the 'reentrant' object before any messages are sent to it. If this seems like a lot of effort just to create a 'reentrant' object, you're correct. Usually one simply avoids this sort of encapsulation, unless there is meta-state which the 'reentrant' object needs to keep. Kurt Kurt Piersol Senior Scientist Usenet: {sun,...}!apple!Piersol Internet: Piersol@apple.com AppleLink: Piersol.k Disclaimer: The opinions presented in this flame do not in any way represent the opinions of anyone, even myself whilst I was writing it.
djones@megatest.UUCP (Dave Jones) (10/03/89)
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.
mhyman@hsfmsh.UUCP (Marco S. Hyman) (10/03/89)
In article <11242@eerie.acsu.Buffalo.EDU> axaris@cs.buffalo.edu (Vassilios Axaris) writes:
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. But I want to be sure...
If I were bold enough to make a rash statement I would say that
object-oriented code MUST be reentrant. However, I don't like absolutes.
Think of the code for a class as being owned by a class and shared by all
objects of the class. In many cases multiple instances of the class
(objects) will be active. This is especially true in simulation systems,
a natural used for OO programming.
--marc
--
// Marco S. Hyman home: {ames,sun}!pacbell!dumbcat!marc
// UUCP: ...!hoptoad!hsfmsh!mhyman I-net: hsfmsh!mhyman@sfsun.west.sun.comech@cbnewsk.ATT.COM (ned.horvath) (10/04/89)
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=
itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) (10/04/89)
In article <4513@internal.Apple.COM> Piersol@apple.com (Kurt Piersol) writes: [Responding to question about "object-oriented code" being re-entrant.] >On the contrary, object-oriented code is in general highly reentrant. [Followed by explaination which can be, I believe, paraphrased as: If there is a re-entrancy problem, it concerns the internal storage/passing of the instance data. His explaination specificly refers to message passing] Don't be a prisoner of your paradigm! [(c) 1989 - Wm A Fulton] :-) (Messages are specific to certain implementations of OOPS) Never the less, Kurt's point (if I understood it correctly), when generalized, is relevant to all OOPS implementations, and is probably what prompted the original question. Although most (probably all) OOPS implementations are as stack oriented languages, information about a specific instance is not defined to be passed on a stack and, thus, *the block of code* which operates on an instance may not re-entrant. I believe, however, that the original remark (questioning re-entrancy) was just conjecture. For example, it's my understanding (although I'm quite a neophyte) that, in C++, the instance info IS passed on the stack. Does anyone know if there are OOPS languages which would be succeptable to the re-entrancy problem? (e.g. in which instance info is passed in global storage) (This would be a very important consideration when choosing a language!) >Since the same code may be shared by many instances of an object class, >each with a different state, the code must be reentrant for the whole >scheme to work. I don't agree with this remark; I think it's the definition of 're-entrant' that's the problem. My understanding is that a block of re-entrant code must support *concurrent* execution by different processes, not just sequential execution by different callers in the same process. Thus, instance data must be part of the "machine state" which is saved. (I may be off base here - it appears that Kurt's point, above, refers to a specific language implementation). Regardless, this point would be very relevant in these days of multi-processors and light weight processes. Well ... hope I haven't made too many basic conceptual errors here; I'm still stuck in the "procedural paradigm". >Kurt Piersol >Senior Scientist Bill Fulton Junior G-Man dcatla!itwaf@gatech.edu [Come on Kurt - we're *Programmers* !]
Piersol@apple.com (Kurt Piersol) (10/04/89)
In article <24517@dcatla.UUCP> itwaf@dcatla.UUCP (Bill Fulton [Sys Admin]) writes: > (Messages are specific to certain implementations of OOPS) Now here's an interesting thought. Am I in fact incorrect in assuming that all OOP systems contain some concept of messaging? I have difficulty imagining why one would bother with OOP at all without an idea of messages, and the fact that the same message selector or ID or whatever has differing behavior based on the receiver or the product of receiver and arguments. I can recall a few systems claiming to support OOP which had no message concept, but instead claimed operator overloading amounted to the same capability. I suppose I just dismissed that notion out of hand. What say the rest of you? > I think it's the definition of 're-entrant' > that's the problem. My understanding is that a block of re-entrant code must > support *concurrent* execution by different processes, not just sequential > execution by different callers in the same process. Thus, instance data must > be part of the "machine state" which is saved. As has been mentioned earlier in this series of messages, there are several possible methods by which one can re-enter the same code. Since in class based systems (or prototype based systems for that matter) the code for all instances (or inheritors) is generally stored in a single location, it must be compiled such that the code depends only on the state of the object in which it is being executed (and perhaps some temporary variables associated with the method). Otherwise, one would have the annoying behavior of mixing state from several instances. As a side effect of this requirement, the code becomes reentrant. The same method (or whatever one wishes to call the code which responds to a message) can be independently in use by several objects in separate threads, or repeatedly within a single recursion chain (especially in cases of mutual recursion). However, if the SAME OBJECT is being used in several threads, some care must be taken lest its internal state become corrupted. Therefore, the objects, as opposed to their code, are not necessarily reentrant. Did this make more sense? The reentrancy is a side effect, but still there. Bill, As for my title, blame Apple for giving it to me. I gotta admit, though, I kinda like it better than Junior G-Man ;-) Kurt Piersol Senior Scientist Usenet: {sun,...}!apple!Piersol Internet: Piersol@apple.com AppleLink: Piersol.k Disclaimer: The opinions presented in this flame do not in any way represent the opinions of anyone, even myself whilst I was writing it.
delacour@inria.inria.fr (Vincent Delacour) (10/04/89)
Object Oriented-ness can easily be achieved by preprocessing, on top of any programming languages that provides functions (or procedures) as values (eg : C, Lisp). For other languages (such as Ada for example), the preprocessing is still possible but relies more heavily on the quality of the compiler and makes separate compilation more difficult to manage. Thus, if the system on which you compile is reentrant, your object- oriented code will be reentrant. [delacour@poly.polytechnique.fr]
jeff@aiai.ed.ac.uk (Jeff Dalton) (10/10/89)
In article <4540@internal.Apple.COM> Piersol@apple.com (Kurt Piersol) writes: >Now here's an interesting thought. Am I in fact incorrect in assuming that >all OOP systems contain some concept of messaging? Well, in Lisp, the difference between (send instance operation other-arg...) and (operation instance other-arg...) doesn't look all that great to me, and I think a similar equivalence might be drawn in other languages. Besides, do we really want to argue that C++ isn't object-oriented just because calling a member function doesn't involve a syntax that looks like sending a message?
david@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (10/13/89)
axaris@cs.buffalo.edu (Vassilios Axaris) writes: >I have recently read somewhere (most likely a magazine article) that object >oriented code must be non reentrant. Is this statement true? No.