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=0.2 required=5.0 tests=BAYES_00,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: 103376,a0224dc3d1e52f3d X-Google-Attributes: gid103376,public From: Mats Weber Subject: Re: Streams and Concurrency Date: 1999/01/08 Message-ID: <36962E36.BA1A61B0@elca-matrix.ch>#1/1 X-Deja-AN: 430223119 Content-Transfer-Encoding: 7bit References: <76c3tv$acs@bgtnsc02.worldnet.att.net> <76cat4$2ldc$1@news.gate.net> <76dn7b$a35@bgtnsc03.worldnet.att.net> <76fe92$46c$1@platane.wanadoo.fr> <76g91o$udt$1@nnrp1.dejanews.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: ELCA Matrix SA Mime-Version: 1.0 Reply-To: Mats.Weber@elca-matrix.ch Newsgroups: comp.lang.ada Date: 1999-01-08T00:00:00+00:00 List-Id: dewar@gnat.com wrote: > In any case, GNAT guarantees that blocking operations CAN > be done within protected objects, of course you may get > deadlock if you do obviously bad things, but certainly > doing IO within a protected object is not such a bad thing, > and this will work fine. We have many customers who depend > on this guarantee. I agree totally. > Yes, yes, of course this is potentially non-portable, but > it makes protected objects enormously more useful. Remember > that there are two advantages of protected objects: > > 1) possibility of more efficient implementation (I say > possibility here because in fact there are many > complications which result in less efficiency than you > might have hoped for in the general case, and in any > case some cases of agent tasks can be optimized in a > corresponding efficient manner. Are you talking about what DEC Ada and Verdix call passive tasks ? > 2) preferable abstraction to a task in some situations > > For my taste 2) is much more important than 1), and the > restriction on blocking operations badly damages the use > of 2). I also see other reasons: 3) In order to protect objects with potentially blocking operations (a socket, a pipe, etc.), you must either use a semaphore implemented as a protected object and call the semaphore _twice_, once for locking and once for unlocking, or you must use a task. Thus the promised performance gain with protected objects is lost. 4) It is another case where the standard enforces things that no compiler can check, neither at compile time nor at run time. Ada 83 had incorrect order dependences in this category, where it was allowed to raise Program_Error if it found one. Fortunately, this was removed from Ada 95 and I think the restriction on blocking protected operations falls in the same category.