Re: entry_barrier, entry_body & entry_declaration

<ada_student@xxxxxxxxx> wrote in message
news:1137694936.037209.266520@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....
> However, what the designers clearly overlooked is that they need
> to allow the programmer to differentiate in the spec between an
> entry with a barrier and one without[since we have stated in
> the previous paragraph that part of the barrier belongs in
> the spec].

Not at all. The interesting property to the client is whether or not the
call can block. And that is *clearly* describable in the syntax: either it
can block (use a protected entry) or it can't block (use a protected
procedure).

Also, remember that there are other ways for a protected entry to block:
specifically requeue. Many of my protected objects have entries with a True
barrier; it's the entry body that decides whether or not the call needs to
wait, and then requeues it if it does. Just putting the barrier into the
spec. would only show part of the equation.

Similarly, task entries can block even without a barrier, simply because the
task may not be executing an appropriate accept statement at the time the
entry is called. So all task entries can block, and there is nothing
interesting about that.

To give more information than just block/no block, Ada would need a formal
precondition notation, which would be in the specification. But Ada doesn't
have this for any sort of call, so their lack for entries is hardly unusual
or surprising. Indeed, few programming languages have any serious support
for preconditions (Eiffel is one exception). We looked at remedying this in
Ada 200Y, but the features to do so turned into complex runtime checks --
and that is the opposite direction as most systems are going (more
compile-time checks) -- and thus it wasn't clear that the features were a
real (as opposed to preceived) benefit to the language and community.

So, you have to describe in the comments for the entry the intended use, and
obviously such comments can't be formally checked. But the description of
functions, procedures, and entries is an important part of the specification
of an Ada callable entity -- the language can only go so far.

Randy.


.

Relevant Pages

  • Re: [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts
    ... According to PCI 3.0 implementation note "Handling MSI-X Vector Shortage," ... Spec says that the port could be designed for software to configure entries ... Namely, if only the first entry is configured, the device is only able to use ...
    (Linux-Kernel)
  • Re: [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts
    ... According to PCI 3.0 implementation note "Handling MSI-X Vector Shortage," ... Spec says that the port could be designed for software to configure entries ... Namely, if only the first entry is configured, the device is only able to use ...
    (Linux-Kernel)
  • Re: [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts
    ... Spec says that the port could be designed for software to configure entries ... Namely, if only the first entry is configured, the device is only able to use ... the value in the register always points to the _valid_ entry in the MSI-X ...
    (Linux-Kernel)
  • Re: entry_barrier, entry_body & entry_declaration
    ... an entry barrier inform an external caller of the entry of when ... In this case, the barrier ... > condition belongs to the spec although the object used to store ... First, read/write can be declared in a package spec, ...
    (comp.lang.ada)
  • Re: [PATCH 5/8] PCI PCIe portdrv: Fix allocation of interrupts
    ... According to PCI 3.0 implementation note "Handling MSI-X Vector Shortage," ... Spec says that the port could be designed for software to configure entries ... Namely, if only the first entry is configured, the device is only able to use ...
    (Linux-Kernel)