Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!bellcore!spectral!sjs
From: sjs@spectral.ctt.bellcore.com (Stan Switzer)
Newsgroups: comp.object
Subject: Re: Parallelism and OOPSs
Message-ID: <17791@bellcore.bellcore.com>
Date: 5 Oct 89 12:30:40 GMT
References: <477@schaefer.MATH.WISC.EDU> <5553@portia.Stanford.EDU>
Sender: news@bellcore.bellcore.com
Reply-To: sjs@bellcore.com (Stan Switzer)
Organization: Bellcore
Lines: 41

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