Re: entry_barrier, entry_body & entry_declaration

On Thu, 2006-01-19 at 10:22 -0800, ada_student@xxxxxxxxx wrote:

> I can only guess that they refer to favorable conditions surrounding
> a procedure call[as in controlling a procedure call by a predicate].

Just to make sure I understand correctly, in your view, does
an entry barrier inform an external caller of the entry of when
it is o.K. to call?

> Let us take the producer/consumer example. In this case, the barrier
> condition belongs to the spec although the object used to store
> the barrier state does not have to.

I don't think it's obvious that the barrier must belong to
the spec of producer/consumer as an abstraction, although
it seems natural to think of barring in the producer/consumer
example.

First, read/write can be declared in a package spec,
but the protecting object can well be declared no earlier than
in the package's body. Clients of the package just call
read/write procedures in the package spec. They don't even
have to "know" that there exists a protected object controlling
read/write.

Second, what should the barrier be here, in your view:

generic
type Item is private;
package p is

protected Sink is
entry put(it: in Item);
end Sink;

end p;


> 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].

An entry always has a barrier (and a queue), as has already been
mentioned, other callable entities being available for different
purposes (without entry_barrier).
I'd actually venture a guess that the designers have not overlooked
the issue. Given how a barrier works, exposing it will unnecessarily
force implementation details to become visible.

(I have had the same question. But I think
I have learned that entry barriers are actually a part
of an implementation description. Hence they don't belong
in in the specification.)

-- Georg


.

Relevant Pages

  • Re: entry_barrier, entry_body & entry_declaration
    ... > entry with a barrier and one without[since we have stated in ... > the spec]. ... can block (use a protected entry) or it can't block (use a protected ... Many of my protected objects have entries with a True ...
    (comp.lang.ada)
  • Re: entry_barrier, entry_body & entry_declaration
    ... 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]. ... It's useful for the client to know when an entry blocks and what will open it, but that's generally more abstract than the actual barrier. ...
    (comp.lang.ada)
  • Re: JVM optimization
    ... > synchronization semantics that affect shared variables that are ... > barrier then it does not need to be considered. ... >>>synchronization is to constrain the possible global sequence of events, ... > the details of the spec, ...
    (comp.lang.java.programmer)
  • Re: Once Again For Your Posting Pleasure - John C. Dvorak Comments On MacOS X
    ... Microsoft is "in trouble" because the barrier to entry into Vista is ...
    (comp.sys.mac.advocacy)
  • Re: entry_barrier, entry_body & entry_declaration
    ... I can only guess that they refer to favorable conditions surrounding ... the barrier state does not have to. ... My point is that of logical design. ... separate spec and body). ...
    (comp.lang.ada)