Re: Writing an Operating System in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1fhgwtz4ezt52.zvep41elk4lq.dlg@40tude.net...
> On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote:
...
>>> You have to be able to derive from a task, that is what active objects 
>>> are.
>>> BTW, you already can do this in Ada 2005. It has task interfaces, but 
>>> this
>>> inheritance is limited to have the depth of 1.
>>
>> I remember reading that now... but is an inheritance level of 1 good
>> enough?
>
> No, it is not. The bottom level is an interface, a quite useless thing
> because it does not provide implementation. The next level is a concrete
> implementation. The train stops there.

You're confusing inheritance of interfaces with inheritance of 
implementation. One of the most important parts of Ada is that it tries to 
strongly separate interfaces and implementation. [I know you know this 
difference, but are purposely ignoring it.]

You can have as much inheritance of interfaces as you want (as you showed in 
your read/write example).

Ada doesn't allow inheritance of implementation for synchronized objects, 
for the very good reason that no one knows how to make inheritance rules 
that doesn't violate the exclusion and ordering rules. We tried for a quite 
a while to make a version of inheritable protected types, but it always led 
to deadlocks, race conditions, or loss of exclusion. (Java has this problem 
in spades.)

We looked at some ideas for very limited inheritance, but it would have been 
quite complex. We didn't think anyone would understand the rules (they 
surely were not intuitive).

By not allowing inheritance at all, we keep all of the mutual exclusion in a 
single object where analysing it for problems is at least possible. Since 
subprogram calls are possible for the sequential code, it doesn't 
necessarily have to be duplicated (although most of the synchronized 
interface objects that we see are quite simple, as anything complex is 
pretty much a lost cause at the start).

Someday the state of the art might change; by not doing anything in Ada 2005 
we left open the possibility for doing it right (whatever that turns out to 
mean) in the future; had we done a lousy job in 2005, we couldn't have 
replaced it in the future without breaking a lot of existing code (which we 
won't do).

                               Randy.