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.6 required=5.0 tests=BAYES_05,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/08/16 Message-ID: <33F5D198.1D46@flash.net>#1/1 X-Deja-AN: 264615864 References: Reply-To: Ken.Garlington@computer.org Organization: Flashnet Communications, http://www.flash.net Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-08-16T00:00:00+00:00 List-Id: Don Harrison wrote: > > Bob Duff wrote: > > :To answer Don's question: protected objects can be locked for read-only > :access, or for read-write access. Read-only access does not exclude > :other readers. > : > :The Ada folks seem to be missing Don's earlier point, which is that in > :Eiffel you can lock a bunch of objects all at once, whereas in Ada, you > :lock just one object at a time (that is, a protected operation X.Op(Y, Z) > :locks X, but not Y and Z (in Ada). > > Thanks (on both counts). Actually, this was the source of my concern (automatic locking of all objects accessed, vs. per-operation locking). However, since this locking is not exactly "automatic" (the "dueling" concept can be used to overcome it), my concern now is more in terms of 1. having this part of the system design spread out amongst the threads, instead of a more object-oriented style of containing it within the protected object, and 2. the compiler complexity required to optimize "benign" calls to avoid locks on a given operation in the first place. Don doesn't see the first issue as a design problem, and doesn't see the second issue as a difficult compiler problem. We'll have to wait for implementations to appear to determine who's right, I guess. > > Don. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Don Harrison donh@syd.csa.com.au