Re: Ravenscar-compliant bounded buffer

["Steve" <nospam_steved94@comcast.net>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:1188977891.197536.21660@r29g2000hsg.googlegroups.com...
> On 5 Wrz, 05:00, "Steve" <nospam_steve...@comcast.net> 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/
>