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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d495ab2e69ad1962 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 05 Sep 2007 23:04:59 -0500 From: "Steve" Newsgroups: comp.lang.ada References: <1188914005.607732.277400@57g2000hsv.googlegroups.com> <1188977891.197536.21660@r29g2000hsg.googlegroups.com> Subject: Re: Ravenscar-compliant bounded buffer Date: Wed, 5 Sep 2007 21:04:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-RFC2646: Format=Flowed; Original Message-ID: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.20.111.206 X-Trace: sv3-UMaClQ90tBBlsHFwhyoUNZkwETeI1NScZNMD3y9K+wdf3vddSaunX+RK7VN6rQSZDVWCbhREnj7RMYQ!GqB+XGu0hK4R/y6+83p6z/yE8qH1KPQzp+4xb+KdTIBt1sCJeqSSOyLT22NR8+XIAOuBUFNLk6/M!OsbxobNnotaOKhq2wEMcy4AXhejOnQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.35 Xref: g2news2.google.com comp.lang.ada:1770 Date: 2007-09-05T21:04:58-07:00 List-Id: "Maciej Sobczak" wrote in message news:1188977891.197536.21660@r29g2000hsg.googlegroups.com... > On 5 Wrz, 05:00, "Steve" wrote: > >> While I don't know much about the Ravenscar profile > > :-) > > In particular, one of the constituents of the Ravenscar profile is > this: > > pragma Restrictions (Max_Protected_Entries => 1); > > which explains the whole issue. > > Bounded buffer is obvious to implement without the above restriction > and I completely agree that using two separate protected objects is an > "abstraction inversion". > The problem is that to be compliant with the Ravenscar profile a > protected type can have *at most one entry* - the rest is really a > question about the "correct hack" that has to be applied for typical > shared resource patterns. > Very interesting. A profile that promotes obscurity. > I argue that my hack is better (more readable and easier to analyze) > than the original hack presented in example 12 of the Ravenscar > document. > Given the restriction, I found your example easy to follow. I don't know where to find the Ravenscar document for comparison. > I will not argue that any of these hacks is better than the > straightforward implementation with two entries, but I can accept the > statement that this is the price for having a uniform convention that > pays off in general, although not necessarily in this particular case. > Ada 83 was restrictive in ways that were found to be overly restrictive for practical application. Some of these retrictions were relaxed with Ada 95. Perhaps the next round of Ravenscar will do the same. While I am not expert on protected types, it is my experience that the predictability of a protected type has more to do with the complexity than the number of entries. Of course that doesn't matter if you must follow Ravenscar. Regards, Steve > Still, since I'm new to Ada, I welcome any comment that can help me > understand it better. > > -- > Maciej Sobczak > http://www.msobczak.com/ >