yunyau@bingvaxu.cc.binghamton.edu (Yun Yau Shih) (04/05/91)
Hi Nets:
I am new to the object-oriented concept. So, I hope I would not insult
any one in this group by asking the following question.
What does it mean by "Several threads can simultaneously enter an object
and execute concurrently." Does it mean REAL CONCURRENCY? How about the
concurrency control, then? Or an object should have a machanism like a
monitor. Any comment/hint/reference is welcomed. Thanks in advance.
--
yunyau
"He who laughs --- lasts!"sakkinen@jyu.fi (Markku Sakkinen) (04/05/91)
In article <1991Apr4.215238.14067@bingvaxu.cc.binghamton.edu> yunyau@bingvaxu.cc.binghamton.edu (Yun Yau Shih) writes: >Hi Nets: > >I am new to the object-oriented concept. So, I hope I would not insult >any one in this group by asking the following question. You are welcome. This group is indeed not reserved only for us who pretend to know everything, to flame each other. >What does it mean by "Several threads can simultaneously enter an object >and execute concurrently." Does it mean REAL CONCURRENCY? How about the >concurrency control, then? Or an object should have a machanism like a >monitor. Any comment/hint/reference is welcomed. Thanks in advance. That's what it means. And right, systems that allow this will need some kind of intra-object concurrency control. One system that I have happened to read about and that works like this is Parallel Objects by Corradi and Leonardi. However, it is probably much more common that an object can be connected to only one thread or process at a time, possibly with the exception of urgent messages that can preempt an ordinary thread. Recommended reading to start with: "Object-Oriented Concurrent Programming", ed. by Yonezawa and Tokoro, MIT Press 1987. Real experts of concurrent OOP, please continue if necessary. Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
cjmchale@cs.tcd.ie (Ciaran McHale) (04/06/91)
In <1991Apr4.215238.14067@bingvaxu.cc.binghamton.edu> yunyau@bingvaxu.cc.binghamton.edu (Yun Yau Shih) writes: >I am new to the object-oriented concept. So, I hope I would not insult >any one in this group by asking the following question. >What does it mean by "Several threads can simultaneously enter an object >and execute concurrently." Does it mean REAL CONCURRENCY? Yes, that's basically what it means. Perhaps there won't be "real" concurrency is there is only one processor and several threads, but the principle is the same regardless of whether the concurrency is "real" or "pseudo." >How about the >concurrency control, then? Or an object should have a machanism like a >monitor. Any comment/hint/reference is welcomed. Thanks in advance. Yes, the object should be able to ensure its own consistency if several threads/activities/processes/whatever-you-call-them are executing in it concurrently. As for references to this ... well it just so happens that that's the area of my research. (No doubt this will surprise many people on comp.window.x and soc.motss:-) I'll post some references in a few minutes. Ciaran. -- Ciaran McHale "There's a lot to be said for verbosity." ---- Department of Computer Science, Trinity College, Dublin 2, Ireland. \ / Telephone: +353-1-772941 ext 1538 FAX: +353-1-772204 \/ Telex: 93782 TCD EI email: cjmchale@cs.tcd.ie
robert@droopy.laas.fr (Robert Valette) (04/09/91)
In article <1991Apr4.215238.14067@bingvaxu.cc.binghamton.edu> yunyau@bingvaxu.cc.binghamton.edu (Yun Yau Shih) writes: > >What does it mean by "Several threads can simultaneously enter an object >and execute concurrently." Does it mean REAL CONCURRENCY? How about the >concurrency control, then? Or an object should have a machanism like a >monitor. Any comment/hint/reference is welcomed. Thanks in advance. >-- Hi, At LAAS-CNRS, Toulouse, France, we are a small group working on OOD (Object Oriented Design) in the case of distributed/concurrent object oriented systems. We try to handle real concurrency within an object and between a collection of objects. Our starting point is HOOD (Hierarchical OOD) and its notion of active objects which are provided with OBCSs (OBject Control Structures). We think that Petri nets are well suited for describing OBCS and analyzing the behavior of a collection of active objects (i.e. a situation with concurrency). We think also that a formal description of the OBCS of an object by means of a Petri net may be an hint to answer to the question: how this object is to be refined? (Objects with internal concurrency are to be refined into a collection of active objects until the obtaining of processes). Then, we think that eventually, at the OOP level (coding) objects do not encapsulate true (or real) concurrency. Is there anybody working in the same direction? .---------------------------------------------------------------------. | Mario PALUDETTO, LAAS-CNRS, 7 Av. du Colonel Roche, | | F-31077 TOULOUSE Cedex France, TEL:++33 61336260, FAX:++33 61553577 | | NET: mario@laas.laas.fr | --------------------------------------------------------------------- | Robert VALETTE, LAAS-CNRS, 7 Av. du Colonel Roche, | | F-31077 TOULOUSE Cedex France, TEL:++33 61336409, FAX:++33 61553577 | | NET: robert@laas.laas.fr | ---------------------------------------------------------------------
paj@mrcu (Paul Johnson) (04/10/91)
In article <5558@laas.laas.fr> robert@droopy.laas.fr (Robert Valette) writes: >Our starting point is HOOD (Hierarchical OOD) and its notion of active objects >which are provided with OBCSs (OBject Control Structures). FLAME ON HOOD (Hierarchical Object-Oriented Design) is not object-oriented. Its mostly a disguised version of functional decomposition. The name is an oxymoron: object-oriented systems are not hierarchical. Hood does not allow recursive use between modules, so your usage graph can only be a DAG. There is no inheritance. The notation distinguishes between `objects' and `data', so if you design a `customer' object you cannot then store that in your linked list object. This is all pretty limiting. You have been HOOD-winked. FLAME OFF (Donning asbestos longjohns) Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244
robert@droopy.laas.fr (Robert Valette) (04/12/91)
In article <894@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >In article <5558@laas.laas.fr> robert@droopy.laas.fr (Robert Valette) writes: > >>Our starting point is HOOD (Hierarchical OOD) and its notion of active objects >>which are provided with OBCSs (OBject Control Structures). > >FLAME ON I respond to the flame! >HOOD (Hierarchical Object-Oriented Design) is not object-oriented. TRUE. Let us say that it is object-based. The aimed coding language is ADA which is not an object-oriented language. >Its mostly a disguised version of functional decomposition. I firmly disagree! Although it is possible to start the design after a functional ``Requirement Analysis'', all the design process is based on an encapsulation of data and procedures by means of objects. There is no public data. An object can only send a method request to an other one and never can directly access its internal data. The absence of inheritance mechanism does not imply the absence of objects (see the discussion in this newsgroup about ``object-oriented and object-based''). >...: object-oriented systems are not hierarchical. What is an object-oriented system (OOP, OOL, OOD, OORA etc.)? It is true that object-oriented languages do not lead to hierarchically structured software. The inheritance graph can be a tree but any node can be instantiated as an object of the same level. In presence of a lot of object classes the absence of a hierarchical structuring is not necessarily an advantage. The advantage of HOOD is precisely to introduce a hierarchical visibility policy among the objects with no connection between it and the inheritance graph. It is possible to have two instances of the same object class which cannot interact directly because they have been designed within two separate branches of the encapsulation hierarchy. The benefit is a better structuring, the cost is that reusability is harder to achieve. >Hood does not allow recursive use between modules, so your usage graph >can only be a DAG. There is no inheritance. The notation >distinguishes between `objects' and `data', so if you design a >`customer' object you cannot then store that in your linked list >object. This is all pretty limiting. The aim of HOOD is an object-based approach in ADA. It is not adapted to object-oriented languages. However I think that some ideas of HOOD are interesting. To conclude, relationship between inheritance, hierarchical structuring, and concurrency is an issue yet to be analyzed. See Article 2006 of comp.object, for example: ||>From: cjmchale@cs.tcd.ie (Ciaran McHale) ||Subject: Re: Concurrency vs Inheritence ||Organization: DSG, Dept. of Comp. Sci., Trinity College, Dublin. || ||This will ||hopefully allow sychronisation code and functional code to be ||inherited/changed independantly of each other. In the same way what HOOD suggests (to me) is that visibility scope, synchronization code and functional code could be inherited/changed independently of each other. .---------------------------------------------------------------------. | Robert VALETTE, LAAS-CNRS, 7 Av. du Colonel Roche, | | F-31077 TOULOUSE Cedex France, TEL:++33 61336409, FAX:++33 61553577 | | NET: robert@laas.laas.fr | ---------------------------------------------------------------------