tasks, protected types and entries

tasks, protected types and entries

[chris.danx]

Hi,

What is the difference between an entry and a procedure?  I think the
difference is that a procedure will always execute regardless of any
condition, but that an entry can have a guard to allow/prevent its execution
if a given condition is satisfied.

So for a (protected) queue, the procedure Enqueue (someitem) would run in
any circumstance and the entry Dequeue (an_item: out sometype) would run
only when it is sensible to do so.  i.e. when there are items in the Queue.

Is that correct?  Is it the same for tasks?


Happy St Paddy's Day,
Chris

Re: tasks, protected types and entries

[chris.danx]

"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:%12l8.9656$%_6.1717935@news11-gui.server.ntli.net...
> Hi,
>
> What is the difference between an entry and a procedure?  I think the
> difference is that a procedure will always execute regardless of any
> condition, but that an entry can have a guard to allow/prevent its
execution
> if a given condition is satisfied.
>
> So for a (protected) queue, the procedure Enqueue (someitem) would run in
> any circumstance and the entry Dequeue (an_item: out sometype) would run
> only when it is sensible to do so.  i.e. when there are items in the
Queue.

That's ambiguous.  I meant to say,

"the procedure Enqueue (someitem) would run when called, but the entry
Dequeue (an_item : out sometype) would run when called, but only when it
made sense to do so. i.e. when there are items in the Queue."

Another thought:  Calls to entries can time out, right?  Does that mean
after a certain time of the Queue being empty the calling task will abandon
the call to Dequeue, possibly doing something else?


Chris

Re: tasks, protected types and entries

[Jim Rogers]

To quote from "Ada as a Second Language" page 860:

"A guard is a construct of the form
    when condition =>
that may precede some or all the alternatives of a selective accept.
A guard has the same form as a barrier in a protected-type entry
body (..) and plays a similar role."

In short, yes, an entry barrier on a protected object does limit
access to the protected object. A guard on a task's selective
accept provides conditions for completion of a rendezvous.

Jim Rogers

chris.danx wrote:

> "chris.danx" <chris.danx@ntlworld.com> wrote in message
> news:%12l8.9656$%_6.1717935@news11-gui.server.ntli.net...
> 
>>Hi,
>>
>>What is the difference between an entry and a procedure?  I think the
>>difference is that a procedure will always execute regardless of any
>>condition, but that an entry can have a guard to allow/prevent its
>>
> execution
> 
>>if a given condition is satisfied.
>>
>>So for a (protected) queue, the procedure Enqueue (someitem) would run in
>>any circumstance and the entry Dequeue (an_item: out sometype) would run
>>only when it is sensible to do so.  i.e. when there are items in the
>>
> Queue.
> 
> That's ambiguous.  I meant to say,
> 
> "the procedure Enqueue (someitem) would run when called, but the entry
> Dequeue (an_item : out sometype) would run when called, but only when it
> made sense to do so. i.e. when there are items in the Queue."
> 
> Another thought:  Calls to entries can time out, right?  Does that mean
> after a certain time of the Queue being empty the calling task will abandon
> the call to Dequeue, possibly doing something else?
> 
> 
> Chris
> 
> 
> 

Re: tasks, protected types and entries

[Sergey Koshcheyev]

"Jim Rogers" <jimmaureenrogers@worldnet.att.net> wrote in message
news:3C94BA62.3050102@worldnet.att.net...
> To quote from "Ada as a Second Language" page 860:
>
> "A guard is a construct of the form
>     when condition =>
> that may precede some or all the alternatives of a selective accept.
> A guard has the same form as a barrier in a protected-type entry
> body (..) and plays a similar role."
>
> In short, yes, an entry barrier on a protected object does limit
> access to the protected object. A guard on a task's selective
> accept provides conditions for completion of a rendezvous.

By the way, what is the difference between a procedure X and an "entry X
when True" in a protected object? I remember that the "entry when True" was
used once in John Barnes' book, but I couldn't find an explanation of the
difference.

Sergey.

Re: tasks, protected types and entries

[Richard Riehle]

"chris.danx" wrote:

> What is the difference between an entry and a procedure?

This is one of the most important and least often address issue
in Ada.  In my classroom, after we have started our unit on
tasking, I have my students recite, in unison,

               "An entry has a queue."

That is so fundamental, and so overlooked.   I believe it is a
starting point for understanding all the associated mechanisms.
The properties of the queue itself, and behavior of its enclosing
task or protected object can be understood only when one
grasps this simple idea.    Yet I encounter programmers who
have been using Ada for years who still don't know this.

> ... a procedure will always execute regardless of any
> condition, but that an entry can have a guard to allow/prevent its execution
> if a given condition is satisfied.

There are no guards on subprograms (procedures and functions).  If there
were, they would be called pre-conditions.    In fact, protected entry
barriers, and task entry guards, are simply a variation-on-the-theme of
pre-conditions.

Richard Riehle

Re: tasks, protected types and entries

[Robert A Duff]

"Sergey Koshcheyev" <serko84@hotmail.com> writes:

> By the way, what is the difference between a procedure X and an "entry X
> when True" in a protected object? I remember that the "entry when True" was
> used once in John Barnes' book, but I couldn't find an explanation of the
> difference.

An entry can requeue; a procedure cannot.  So if you want to do
something unconditionally and then perhaps requeue, you need a "when
True" entry barrier.

- Bob

Re: tasks, protected types and entries

[Ehud Lamm]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C94F235.80C7166A@adaworks.com...
>
> There are no guards on subprograms (procedures and functions).  If there
> were, they would be called pre-conditions.    In fact, protected entry
> barriers, and task entry guards, are simply a variation-on-the-theme of
> pre-conditions.
>

BTW: The literature often uses the terms "behavioral contract" and
"synchronization contract" to distinguish these two types of contracts.

Ehud Lamm

Re: tasks, protected types and entries

[Pat Rogers]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C94F235.80C7166A@adaworks.com...
> "chris.danx" wrote:
>
> > What is the difference between an entry and a procedure?
>
> This is one of the most important and least often address issue
> in Ada.  In my classroom, after we have started our unit on
> tasking, I have my students recite, in unison,
>
>                "An entry has a queue."

Unless the Real-Time Annex is used, with the Ceiling_Locking policy.  Then there
is no need for a queue.

>
> That is so fundamental, and so overlooked.   I believe it is a
> starting point for understanding all the associated mechanisms.
> The properties of the queue itself, and behavior of its enclosing
> task or protected object can be understood only when one
> grasps this simple idea.    Yet I encounter programmers who
> have been using Ada for years who still don't know this.
>
> > ... a procedure will always execute regardless of any
> > condition, but that an entry can have a guard to allow/prevent its execution
> > if a given condition is satisfied.
>
> There are no guards on subprograms (procedures and functions).  If there
> were, they would be called pre-conditions.    In fact, protected entry
> barriers, and task entry guards, are simply a variation-on-the-theme of
> pre-conditions.
>
> Richard Riehle
>

Re: tasks, protected types and entries

[Bo Sanden]

Another way to view this is to talk about "exclusion" and "condition"
synchronization. Procedures have exclusion synchronization, which means that if
you call a procedure that is currently being run by another task, you get to wait
a little until the previous task is done. If things are well designed, the
likelihood that yet another task should try to call the same procedure and also be
put waiting is almost nil, so there is little reason to worry about which waiting
task gets to proceed first.

Condition synchronization is when a task must wait for some condition in the
problem domain to become true. For example, the task may need access to some
problem domain resource, such as a track segment in a switchyard or an automated
guided vehicle (AGV) in a flexible manufacturing system. This wait is on an
average much longer than the exclusion wait and we want the tasks that need the
AGV to wait in a first-in-first-out queue (within priorities). This is what a
queue is for. It organizes the waiting tasks when the wait can be expected to be
long enough to warrant it.

The wait could also be for some software resource such as a buffer. A task that
calls Get( ) is queued if the buffer is empty, and a task that calls Put( ) is
queued if the buffer if full. In these cases the wait can again be much longer
than the time it takes for a task to get out of a protected procedure, and we want
the waiting tasks to be properly queued.

Bo Sanden


Richard Riehle wrote:

> "chris.danx" wrote:
>
> > What is the difference between an entry and a procedure?
>
> This is one of the most important and least often address issue
> in Ada.  In my classroom, after we have started our unit on
> tasking, I have my students recite, in unison,
>
>                "An entry has a queue."
>
> That is so fundamental, and so overlooked.   I believe it is a
> starting point for understanding all the associated mechanisms.
> The properties of the queue itself, and behavior of its enclosing
> task or protected object can be understood only when one
> grasps this simple idea.    Yet I encounter programmers who
> have been using Ada for years who still don't know this.
>
> > ... a procedure will always execute regardless of any
> > condition, but that an entry can have a guard to allow/prevent its execution
> > if a given condition is satisfied.
>
> There are no guards on subprograms (procedures and functions).  If there
> were, they would be called pre-conditions.    In fact, protected entry
> barriers, and task entry guards, are simply a variation-on-the-theme of
> pre-conditions.
>
> Richard Riehle

--
Dr. Bo I. Sand�n
Professor of Computer Science
Colorado Technical University
Colorado Springs, CO, U.S.A.
iis-web.coloradotech.edu/bsanden
(0719) 590-6733

Re: tasks, protected types and entries

[Jeffrey Carter]

Pat Rogers wrote:
> 
> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3C94F235.80C7166A@adaworks.com...
> > "chris.danx" wrote:
> >
> > > What is the difference between an entry and a procedure?
> >
> > This is one of the most important and least often address issue
> > in Ada.  In my classroom, after we have started our unit on
> > tasking, I have my students recite, in unison,
> >
> >                "An entry has a queue."
> 
> Unless the Real-Time Annex is used, with the Ceiling_Locking policy.  Then there
> is no need for a queue.

This is incorrect. Even with ceiling locking, an entry needs a queue. If
the entry barrier is false, ceiling locking does not prevent multiple
tasks from calling the same entry.

-- 
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail

Re: tasks, protected types and entries

[Pat Rogers]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3C95460D.4B2419D0@acm.org...
> Pat Rogers wrote:
> >
> > "Richard Riehle" <richard@adaworks.com> wrote in message
> > news:3C94F235.80C7166A@adaworks.com...
> > > "chris.danx" wrote:
> > >
> > > > What is the difference between an entry and a procedure?
> > >
> > > This is one of the most important and least often address issue
> > > in Ada.  In my classroom, after we have started our unit on
> > > tasking, I have my students recite, in unison,
> > >
> > >                "An entry has a queue."
> >
> > Unless the Real-Time Annex is used, with the Ceiling_Locking policy.  Then
there
> > is no need for a queue.
>
> This is incorrect. Even with ceiling locking, an entry needs a queue. If
> the entry barrier is false, ceiling locking does not prevent multiple
> tasks from calling the same entry.
>

Yes, of course you are right -- it is the lock that is not necessary.  Mea
culpa.  Typing faster than thinking...

Re: tasks, protected types and entries

[john mann]

... and you can have an access-to-procedure type, but not an access-to-entry type

Re: tasks, protected types and entries

[chris.danx]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C94F235.80C7166A@adaworks.com...
> "chris.danx" wrote:
>
> > What is the difference between an entry and a procedure?
>
> This is one of the most important and least often address issue
> in Ada.
>
> In my classroom, after we have started our unit on
> tasking, I have my students recite, in unison,
>
>                "An entry has a queue."

You mean that several tasks can issue a request on an entry, and they are
serviced in a first come, first served fashion?

ok, I think I understand the difference now.