From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d87fcae02ce5c10a X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Synchronizing on multiple distinict resources Date: Wed, 11 Aug 2004 15:52:34 +0200 Message-ID: <1f4ugyz3ig9rc$.785e2wqt1qyg$.dlg@40tude.net> References: <7ebaa24d.0408021054.4abc6e73@posting.google.com> <782e906e.0408101051.5e122af0@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de mAX7Ki1xEKzE7DUP4tR+RQUz7txHbcwdofs3rNwcbByXJlKKs= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:2669 Date: 2004-08-11T15:52:34+02:00 List-Id: On 10 Aug 2004 11:51:11 -0700, Chad R. Meiners wrote: > "Dmitry A. Kazakov" wrote in message news:... >> One could also speculate about further Ada extensions towards: > > Such speculation would be welcome ;) For instance I became more > interested in the problem with sychronizing upon multiple resources > after reading a colleague's paper. > > http://www.cse.msu.edu/~behrends/universe/fse00.pdf > > Which handles multiple synchronizations with synchronization > contracts. It is much desirable to have contracts. Especially is they would be provable. However, from the paper it is not clear to me how composability is achieved. (Ada's protected objects and tasks are practically not composable.) Well, what happens with the "concurrency" clause upon inheritance? How to hide/expose/override such clauses? What about generic and class-wide concurrency? Will separate compilation and linkage be possible? How to deal with actions split across processes? I mean things represented by the requeue statement in Ada. It seems that in the universe model such things will be impossible. I cannot say whether this constraint is important or not, but quite often I found requeueing the only way to do some things. Further I'd like to preserve both views on concurrency, i.e. tasks and protected objects. I am not convinced that protected/active objects alone are enough flexible. >> 1. multiple protected actions / rendezvous (to queue to two chopsticks) > > Perhaps something like > > procedure Eat(Left, Right : in out Chop_Stick) is > Synchronize Left and Right; -- Exclusive access until end of > procedure > begin > ... > end Eat; One could allow "free" entry points with normal syntax: protected type Chop_Stick is procedure Release; -- A "member" procedure private Free : Boolean; end Chop_Stick; -- This is not Ada entry Seize (Left, Right : in out Chop_Stick); -- Not a "member", but still a primitive operation entry Seize (Left, Right : in out Chop_Stick) when Left.Free and Right.Free is -- Dispatching parameters are allowed to appear in barriers begin Left.Free := False; Right.Free := False; end Seize; >> 2. extensible protected objects / tasks with multiple inheritance (to >> inherit a pair of chopsticks twice from a chopstick) > > Not sure how this would work. In the case of philosophers it will not, because chopsticks pairs overlap. But the rationale is same: let I want to combine two protected objects in one: -- This is not Ada protected type Pair_Of_Sticks is private entry Seize; procedure Release; end Pair_Of_Sticks; ... private protected type Pair_Of_Sticks is new Left : Chop_Stick; Right : Chop_Stick; -- Implementation: entry Seize when Left.Free and Right.Free is -- Can use inherited members in barriers begin Left.Free := False; Right.Free := False; end Seize; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de