Let's see whether we can get some consensus. By a traversal I mean here a Demeter/Java traversal like "allX": Company { traversal void allX(Visitor1 v1) {to X;} Crista, Binoy, Geoff, Kedar and I had a discussion yesterday afternoon which concluded that we should first synchronize just on method names defined in verbatim methods. That would include pp names once they are a part of Demeter Java. It looks like that synchronizing on traversals would lock too much. We would like to refer to before/after/around methods in mutex sets. Then as we understand this synchronization constructs more we can wee whether we need to add the capability Johan (and Crista) suggested initially. -- Karl =============== Crista proposes the following approach to synchronization in Demeter/Java: We want to synchronize on entire traversals, pieces of a traversal and before/after/around methods. The strategy is to use selfex and mutex but to allow more complex objects than only qualified method names. Examples: (t is a traversal) selfex {C.t}: no other thread can start the same traversal. mutex{A.t1(X,Y), A.t2(X,Y), A.t3(X,Y)) the traversals t1, t2 and t3 are mutually exclusive at classes X and Y only. mutex{A.t1(strategy s1), A.t2(strategy s1)} the traversals t1 and t2 are mutually exclusive at classes defined by strategy s1. How does this look? -- Karl From johan@ccs.neu.edu Tue Jun 3 14:26:13 1997 Received: from carbon.ccs.neu.edu (carbon.ccs.neu.edu [129.10.114.110]) by amber.ccs.neu.edu (8.8.4/8.7.3) with ESMTP id OAA09356; Tue, 3 Jun 1997 14:26:11 -0400 (EDT) Received: (johan@localhost) by carbon.ccs.neu.edu (8.8.4/8.6.4) id OAA04755; Tue, 3 Jun 1997 14:26:10 -0400 (EDT) Date: Tue, 3 Jun 1997 14:26:10 -0400 (EDT) Message-Id: <199706031826.OAA04755@carbon.ccs.neu.edu> From: Johan Ovlinger To: lieber@ccs.neu.edu CC: binoy@ccs.neu.edu, dougo@ccs.neu.edu, ghulten@ccs.neu.edu, jayantha@ccs.neu.edu, kedar@ccs.neu.edu, lieber@ccs.neu.edu, boaz@ccs.neu.edu, crista@ccs.neu.edu, marshajh@bc.edu, taposadm@ccs.neu.edu In-reply-to: <199706031757.NAA17309@stockberg.ccs.neu.edu> (message from Karl Lieberherr on Tue, 3 Jun 1997 13:57:58 -0400 (EDT)) Subject: Re: coordination objects Status: R [Crista's proposal] Yes. Good. I like the ability to have incremental control over what is excluded. This is exactly what I had in mind when I suggested that traversals be the unit of exclusion. Johan From dougo@ccs.neu.edu Tue Jun 3 15:16:16 1997 Received: from vega.neu.edu (vega.ccs.neu.edu [129.10.115.77]) by amber.ccs.neu.edu (8.8.4/8.7.3) with SMTP id PAA11271; Tue, 3 Jun 1997 15:16:14 -0400 (EDT) Received: by vega.neu.edu (SMI-8.6/SMI-SVR4) id PAA08809; Tue, 3 Jun 1997 15:15:55 -0400 Date: Tue, 3 Jun 1997 15:15:55 -0400 Message-Id: <199706031915.PAA08809@vega.neu.edu> From: Doug Orleans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Karl Lieberherr Cc: binoy@ccs.neu.edu, ghulten@ccs.neu.edu, jayantha@ccs.neu.edu, johan@ccs.neu.edu, kedar@ccs.neu.edu, boaz@ccs.neu.edu, crista@ccs.neu.edu, marshajh@bc.edu, taposadm@ccs.neu.edu Subject: Re: coordination objects In-Reply-To: <199706031757.NAA17309@stockberg.ccs.neu.edu> References: <199706031757.NAA17309@stockberg.ccs.neu.edu> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid X-Face: (4D-osoq?}7M3\EgvbWKo Examples: > (t is a traversal) > > selfex {C.t}: no other thread can start the same traversal. > > mutex{A.t1(X,Y), A.t2(X,Y), A.t3(X,Y)) the traversals t1, t2 and t3 > are mutually exclusive at classes X and Y only. > > mutex{A.t1(strategy s1), A.t2(strategy s1)} the traversals t1 and t2 > are mutually exclusive at classes defined by strategy s1. A traversal by itself is probably not what you want to synchronize on; you want to synchronize on a specific combination of traversal and visitor(s). A single traversal might be shared by several visitors, and there might be no overlap in the variables that the visitors touch. We probably want to synchronize on operations (aka propagation patterns), which I hope to add to Demeter/Java soon (after quals). They essentially give a name to a particular combination of traversal + visitor. --Doug From johan@ccs.neu.edu Tue Jun 3 15:38:26 1997 Received: from carbon.ccs.neu.edu (carbon.ccs.neu.edu [129.10.114.110]) by amber.ccs.neu.edu (8.8.4/8.7.3) with ESMTP id PAA12084; Tue, 3 Jun 1997 15:38:23 -0400 (EDT) Received: (johan@localhost) by carbon.ccs.neu.edu (8.8.4/8.6.4) id PAA04344; Tue, 3 Jun 1997 15:38:22 -0400 (EDT) Date: Tue, 3 Jun 1997 15:38:22 -0400 (EDT) Message-Id: <199706031938.PAA04344@carbon.ccs.neu.edu> From: Johan Ovlinger To: dougo@ccs.neu.edu CC: lieber@ccs.neu.edu, binoy@ccs.neu.edu, ghulten@ccs.neu.edu, jayantha@ccs.neu.edu, kedar@ccs.neu.edu, boaz@ccs.neu.edu, crista@ccs.neu.edu, marshajh@bc.edu, taposadm@ccs.neu.edu In-reply-to: <199706031915.PAA08809@vega.neu.edu> (message from Doug Orleans on Tue, 3 Jun 1997 15:15:55 -0400) Subject: Re: coordination objects Status: R I started out not agreeing with doug, but now I find that I do. Oh well. Read on. Dou has a point: that Traversals+Visitor is not a perfect unit of exclusion. Ideally, we would like to say that two visitors that perform a certain form of abstract operation may not simultaneously be in a subgraph of the CG. We want a functional categorisation of visitors and a structural decomposition of the CG. What we have is a structural decompostion of both. I claim that the coupling of traversals and visitor classes is "good enough" so that traversals are a useful unit of exclusion. Since in my humble experience inheritance is of little usefullness for programming Visitors, we can use subclassing to organize visitors into functional sets (use structural decomp to model the functional decomp). Thus the allClassDefs traversal might carry an instance of the ClassDefModifing visitor, which has several possible subclasses, sharing no common inherited variables, but lumped together because they need to be in the same exclusion set. It's a hack, but I think its ok. So I end up disagreeing with Doug anyway. I think a Traversal is a very close approximation of what we want. I freely admit to not knowing enough about Propagation patterns to judge their fitness wrt exlcusion. Johan