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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,fb45e48e8dddeabd X-Google-Attributes: gid103376,public X-Google-Thread: ffc1e,fb45e48e8dddeabd X-Google-Attributes: gidffc1e,public From: Karel Th�nissen Subject: Re: Ada Protected Object Tutorial #1 Date: 1999/12/17 Message-ID: <385984BC.1FB1@hello.nl>#1/1 X-Deja-AN: 561744264 Content-Transfer-Encoding: 8bit References: <839toq$pu$1@bgtnsc03.worldnet.att.net> <3858E5B3.9AB004E9@bton.ac.uk> Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: abuse@nl.uu.net X-Trace: porthos.nl.uu.net 945390410 1396 212.153.213.224 (17 Dec 1999 00:26:50 GMT) Organization: Hello Technologies, Netherlands Mime-Version: 1.0 NNTP-Posting-Date: 17 Dec 1999 00:26:50 GMT Newsgroups: comp.programming.threads,comp.lang.ada Date: 1999-12-17T00:26:50+00:00 List-Id: John English wrote: > > Kaz Kylheku wrote: > > This approach to design is generally wasteful. It's more reasonable to have > > public methods which always lock and unlock, and unprotected methods which > > assume that an object is already locked. It's also useful for an object > > to expose lock and unlock methods, and expose unprotected operations, so that > > the user of the object can compose a sequence of operations into an indivisible > > block. > > Congratulations, you've just invented the semaphore... :-) I noticed the smiley, but to be fair to the original poster this is not quite true. He noticed that protected types are great if the caller needs a single service from the protected type, but they are not that great if you need more than one service from the same protected type. Not only does the protected type solution require locking and unlocking for every single service invocation, instead of one pair for the whole deal, it also cannot avoid the situation that other tasks are serviced in between two calls. This can make correctness difficult to prove. Mr Kylheku did not claim any invention, he was just pointing out a disadvantage of the protected type mechanism. BTW, even the protected type uses a semaphore so his idea would not have been original and not patentable (-8 I am wondering whether there is a clean solution to the problem that Mr Kylheku presented: how can we combine several protected type services into one transaction-like construct without requiring clairvoyance or retrofitting. Of course we can always go back and change the code in the protected type and offer the combined invocation of the multiplicity of services as a single integrated service, but this option requires recoding, recompilation and re-verification. Solutions that do not use protected types are also welcome, if they are safe and clean. So bluntly providing the services without any concurrency protection and counting for the caller's willingness to use a semaphore is outside the competition. -- Groeten, Karel Th�nissen Hello Technologies develops high integrity software for complex systems