wayne@schaefer.MATH.WISC.EDU (Rick Wayne) (10/05/89)
i've done some fiddling with Smalltalk/V. there you have my entire expert status on OOPSs. since objects decompose so nicely into independent entities (at least abstractly), wouldn't this provide an excellent hook for introducing parallelism? could be loosely or tightly coupled; message passing would either be memory-to-memory transfer or network sends. this sounds so obvious that i'm sure SOMEBODY must be doing it (chorus of "that's the whole idea!" in the background), but in all the seminars i've sat through, this specific idea was never raised. i'm so interested in the answer that i've risked my lucrative patent rights by disclosing this idea. comments? rick wayne@wisplan.uwex.wisc.edu
dchapman@portia.Stanford.EDU (David Chapman) (10/05/89)
In article <477@schaefer.MATH.WISC.EDU> wayne@schaefer.MATH.WISC.EDU (Rick Wayne) writes: >since objects decompose so nicely into independent entities (at least >abstractly), wouldn't this provide an excellent hook for introducing >parallelism? could be loosely or tightly coupled; message passing would >either be memory-to-memory transfer or network sends. It's a very nice way to represent the communications between parallel processes but you still have to write a parallel program. People are still trying to define generalized methodologies for parallel programming, though. OOP in itself is not enough; see the current thread on re-entrant code for one reason why not. >this sounds so obvious that i'm sure SOMEBODY must be doing it (chorus of >"that's the whole idea!" in the background), but in all the seminars i've >sat through, this specific idea was never raised. > >i'm so interested in the answer that i've risked my lucrative patent rights >by disclosing this idea. comments? It's so obvious that the Patent Office would never grant you a patent on it. It must not be "obvious to one well-versed in the field." As the proud owner of a patent (#4,849,313) I can assure you that this is true. I've also noticed the link between message-passing operating systems and OOLs for a couple of years, and since I'm "well versed"... :-)
sjs@spectral.ctt.bellcore.com (Stan Switzer) (10/05/89)
In article <5553@portia.Stanford.EDU> dchapman@Portia.Stanford.EDU (David Chapman) writes: > In article <477@schaefer.MATH.WISC.EDU> > wayne@schaefer.MATH.WISC.EDU (Rick Wayne) writes: > >since objects decompose so nicely into independent entities (at least > >abstractly), wouldn't this provide an excellent hook for introducing > >parallelism? could be loosely or tightly coupled; message passing would > >either be memory-to-memory transfer or network sends. > > It's a very nice way to represent the communications between parallel > processes but you still have to write a parallel program. People are > still trying to define generalized methodologies for parallel > programming, though. OOP in itself is not enough; see the current > thread on re-entrant code for one reason why not. Indeed, it seems like everyone has been trying to figure out how to do this lately. For a moment, I'd like to leapfrog the question of re-entrancy and ask about the idea of "transactions" in an Object-Oriented model. This could be considered relative to ordinary objects, persistent objects, or OO-databases. For my purposes, a transaction is a set of operations on diverse objects such the the entire transaction is atomic and isolated. It is atomic in that either all of the operations are performed or none of them, and isolated in that the partial results of a transaction are not visible to other transactions. Just to make it interesting, suppose that we either allow a sequential program to engage in multiple simultaneous unrelated transactions, or we have independent processing threads. Also, transaction processing schemes frequently handle resource deadlocks by aborting the the processes involved. Is this a good idea for OO transactions? Is there a better exception handling mechanism available? Consider it a two-part question: multiple transactions per execution thread, and multiple threads of at most one transaction each. Does anyone have any ideas? Can you refer me to any papers? Stan Switzer sjs@bellcore.com
creemer@catalonia.sw.mcc.com (David Creemer) (10/05/89)
In article <477@schaefer.MATH.WISC.EDU>, wayne@schaefer.MATH.WISC.EDU (Rick Wayne) writes: > since objects decompose so nicely into independent entities (at least > abstractly), wouldn't this provide an excellent hook for introducing > parallelism? could be loosely or tightly coupled; message passing would > either be memory-to-memory transfer or network sends. Check out "Object-Oriented Concurrent Processing," from the MIT Press. It contains several articles on just this subject. David Creemer, MCC Software Technology Program 9390 Research, Kaleido II Bldg., Austin, Texas 78759 512 338-3403 creemer@sw.mcc.com davidz@cs.utexas.edu
alms@cambridge.apple.com (Andrew L. M. Shalit) (10/05/89)
In article <477@schaefer.MATH.WISC.EDU> wayne@schaefer.MATH.WISC.EDU (Rick Wayne) writes:
since objects decompose so nicely into independent entities (at least
abstractly), wouldn't this provide an excellent hook for introducing
parallelism? could be loosely or tightly coupled; message passing would
either be memory-to-memory transfer or network sends.
this sounds so obvious that i'm sure SOMEBODY must be doing it (chorus of
"that's the whole idea!" in the background), but in all the seminars i've
sat through, this specific idea was never raised.
Check out the Actors papers by Carl Hewitt and Henry Lieberman.
This was landmark work a few years ago. They do exactly what
you describe, and go into great detail.
Their work is unrelated to the oo-language Actor which runs under
windows (and came a few years later).sanjay@athena.mit.edu (Sanjay Ghemawat) (10/06/89)
You should look at the following paper on Argus, a variant of CLU for programming transaction-based distributed systems. Argus supports multiple threads and nested multi-site transactions. "Distributed Programming in Argus" by Barbara Liskov Communications of the ACM. Volume 31, Number 3 March, 1988. Pages 300-312 -Sanjay
ttwang@polyslo.CalPoly.EDU (Thomas Wang) (10/06/89)
sjs@bellcore.com (Stan Switzer) writes: >Indeed, it seems like everyone has been trying to figure out how to do >this lately. For a moment, I'd like to leapfrog the question of >re-entrancy and ask about the idea of "transactions" in an >Object-Oriented model. This could be considered relative to ordinary >objects, persistent objects, or OO-databases. OO languages should be free of concepts such as "transactions", "processes", and "IPC". These are best implemented by the operating system. The OO languages can be used to provide nice interface to the raw operating system services. This way, the OO language can be made portable. One only has to re-write the non-portable interface classes. An ideal operating system should offer Client-Server support as a basic service. >Stan Switzer sjs@bellcore.com -Thomas Wang ("This is a fantastic comedy that Ataru and his wife Lum, an invader from space, cause excitement involving their neighbors." - from a badly translated Urusei Yatsura poster) ttwang@polyslo.calpoly.edu
hws@icsib1.Berkeley.EDU (Heinz Schmidt) (10/06/89)
> Indeed, it seems like everyone has been trying to figure out how to do > this lately. For a moment, I'd like to leapfrog the question of > re-entrancy and ask about the idea of "transactions" in an > Object-Oriented model. This could be considered relative to ordinary > objects, persistent objects, or OO-databases. > ... > Also, transaction processing schemes frequently handle resource > deadlocks by aborting the the processes involved. Is this a good idea > for OO transactions? Is there a better exception handling mechanism > available? Consider it a two-part question: multiple transactions per > execution thread, and multiple threads of at most one transaction > each. > > Does anyone have any ideas? Can you refer me to any papers? Sometime ago I read about an OO database system called Statice that supports similar operations. It is written in FLAVORS (one of the OO Lisp dialects) and around FLAVORS (i.e. it stores flavor instances). Statice is implemented on top of TCP/IP protocols to support multiuser access accress the network. Transactions are atomic and can be nested, they operate on a cached image of DB pages und the cached pages are backep-up only when the toplevel transaction is successful. Many instances can live on one page and one instance can live across many pages. To the application programs the instances appear to live in the programs' address space. So method execution is usually inside some transaction. The lowest level atomic transactions compete for pages (locking, only one thread can own a page at a time) and deadlocks in this competition are dynamically detected. When a deadlock is detected the transaction is aborted (rollback) and within the transaction nesting level of your application program you have to handle the exceptional condition. For instance you could retry after some delay -- useful if your methods didn't have sideeffects so far other than on the persistent objects, which were automatically rolled back to a consistent state -- or, you could decide to abort this nesting level too, and so on... Unfortunately I don't recall the reference but I believe there were some papers around this theme in the last OOPSLA 88 conf. proceedings. I think it is a good idea to allow a transaction to operate on many related objects because data integrity may impose some global consistency constraints that you may not be able to maintain in a single operation on a single object when you have to update the DB. Obviously the application programmer can save quite some programming effort with transactions and rollbacks, in a situation where (a) there is shared data, (b) update capabilities on these data are granted non-exclusively, and, (c) there are global integrity constraints to be maintained whenever data can be observed by other application programs on different threats (in other words, at all points between low-level atomic transactions). - which objects should be persistent and hence shared by many threads running over different hosts in a network? - granularity of locking: objects or chunks of objects like above pages? - when is locking alone (without rollback) sufficient/more appropriate for synchronizing threads running over many objects? - are there techniques/tools that could help detect 'out-of-place' sideeffects, I mean sideeffects on non-persistent objects during transactions? -- Heinz Schmidt hws@icsi.berkeley.edu
champeaux@hplabsz.HPL.HP.COM (Dennis de Champeaux) (10/07/89)
Simula is one of the roots of the oo-bandwagon. From the concurrency in Simula to parallelism is just a little step. Thus you, Schaefer.MATH.WISC.EDU, rediscovered a feature that was "lost" over time. FYI. We conceive the objects in our oo-analysis work as being autonomous, little machine like entities. Parallism is the rule. Thus, a main task of oo-design - as we see it now - is to decide how to squeeze these analysis objects into sequential behavior. Since current oop languages are weak on parallelism/ concurrency.
rice@dg-rtp.dg.com (Brian Rice) (10/08/89)
In article <477@schaefer.MATH.WISC.EDU> wayne@schaefer.MATH.WISC.EDU (Rick Wayne) writes: > since objects decompose so nicely into independent entities (at least > abstractly), wouldn't this provide an excellent hook for introducing > parallelism? could be loosely or tightly coupled; message passing would > either be memory-to-memory transfer or network sends. Check out Linda, a delightful methodology for parallel programming. A good introduction is Ahuja, Carriero, and Gelernter, "Linda and Friends," _Computer_, August 1986, pp. 26-34. (_Computer_, in case that's not your normal leisure reading, is a publication of the IEEE.) Prolog-heads will like Linda too. Brian Rice rice@dg-rtp.dg.com (919) 248-6328 DG/UX Product Assurance Engineering Data General Corp., Research Triangle Park, N.C. "My other car is an AViiON."