Multiple entry tasks

Multiple entry tasks

[Lutz Donnerhacke]

Simple problem, but no clue:

I have a task with multiple entry points. I'd like to serve some entries
before the rest and like to have a terminate alternative. How should I solve
this? (Currently I added a protected type and used it, but this violates the
encapsulation)

Re: Multiple entry tasks

[Marin David Condic]

Sounds like you want some version of guarded entries in a select statement.
I have not attempted to do this before (kids: don't try this at home - we
*are* trained professionals!), nor have I run this past a compiler (spank me
for this later if it doesn't work) but I *think* you want some version of
the following:

select
    when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
        accept Entry3 ;
    when (Entry1'Count <= 0) =>
        accept Entry2 ;
or
    accept Entry1;
else
    terminate;
end select ;

Let me know if a) some variation of this compiles and b) it does what you
intended...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Lutz Donnerhacke" <lutz@iks-jena.de> wrote in message
news:slrn9dralj.k4.lutz@taranis.iks-jena.de...
> Simple problem, but no clue:
>
> I have a task with multiple entry points. I'd like to serve some entries
> before the rest and like to have a terminate alternative. How should I
solve
> this? (Currently I added a protected type and used it, but this violates
the
> encapsulation)

Re: Multiple entry tasks

[Ted Dennison]

In article <9bkevj$61k$1@nh.pace.co.uk>, Marin David Condic says...
>
>*are* trained professionals!), nor have I run this past a compiler (spank me
>for this later if it doesn't work) but I *think* you want some version of
>the following:
>
>select
>    when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
>        accept Entry3 ;

or 

>    when (Entry1'Count <= 0) =>
>        accept Entry2 ;
>or
>    accept Entry1;
>else
>    terminate;
>end select ;


I don't think the guards get recalcuated when new entries come in, only when the
top of the select statement is reached. Thus if nothing is available then, it
will continue to wait indefinitely for Entry1, even if an Entry2 or Entry3 comes
in later.

One way to get some entries to have priority over others would be to use "pragma
Queuing_Policy (Priority_Queuing);" With that set, the entries will be accepted
in the order of the priority of their tasks. The drawbacks to this are that your
scheme depends on task priorities, which might not mesh well with what you are
trying to do, and that this pragma requires that your compiler supports the
Real-Time annex (D). If you do it this way, you are really prioritizing the
*clients* (rendezvous initiating tasks), not the entires.

An different way, that prioritizes the entries themselves, is to use cascading
select-else structures:

select
accept Entry1;
else
select
accept Entry2;
else
select
accept Entry1;
or
accept Entry2;
or
accept Entry3;
or
terminate;
end select;
end select;
end select;


A third possiblity, that works with a single entry, is to keep track of the
highest priority entry (this part is tricky), and use the "requeue" statement
creatively. How exactly to accomplish this depends a lot on your scheme for
setting and keeping track of priorities, and can get quite interesting, so I
won't burden everyone here with an example (as much as I'd love to. Requeue is
really fun to play with).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Ted Dennison]

In article <vOkD6.1839$D4.178910@www.newsranger.com>, Ted Dennison says...
>
>In article <9bkevj$61k$1@nh.pace.co.uk>, Marin David Condic says...
>>
>>select
>>    when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
>>        accept Entry3 ;
>
>or 
>
>>    when (Entry1'Count <= 0) =>
>>        accept Entry2 ;
>>or
>>    accept Entry1;
>>else
>>    terminate;
>>end select ;
>
>
>I don't think the guards get recalcuated when new entries come in, only when the
>top of the select statement is reached. Thus if nothing is available then, it
>will continue to wait indefinitely for Entry1, even if an Entry2 or Entry3 comes
>in later.


Doh! I misread the conditionals. If waiting occurs, all the guards will be
*open*. That should work fine (assuming the "or" is added, of course). If
multiple rendezvous become active before this task gets around to accepting one,
I suppose the priority principle could be violated. But that's a pretty marginal
case. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Marin David Condic]

Thanks for catching my typo with the missing "or" part.

I don't think this is a simple problem to solve. Almost anything one does to
fiddle with the availability of entries is going to make the complexity go
way up real fast. As you observe, it is a way of trying to prioritize the
entries. Ada would prefer it if you prioritized the tasks.

Cascading the selects is an interesting mechanism. I'm not sure there is any
answer that will be definitive. (Short of a language mod allowing one to
prioritize entries?) Maybe the real answer is to divide the entries up into
individual tasks and assign priorities? (This is, of course, a structural
change that gets away from the original question.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Multiple entry tasks

[Marin David Condic]

If multiple rendezvous become active before you hit the select, I'd imagine
that they would have to be queued according to the priority of the tasks
that called the entries. It is a marginal case but probably worth thinking
about for a minute anyway...

If two tasks of the same priority were calling, say, Entry2 - then its a
coin toss as to which gets there first.

If two tasks of the same priority were calling different entries, then the
priority of the entry would decide which got to run.

If two tasks of different priority call the same entry, then the higher
priority task gets it.

If two tasks of different priorities call different entries, then you might
get a priority inversion - if both Entry2 and Entry3 have callers, then
Entry3 is blocked when you get to evaluating it.So even if the task calling
Entry3 is of higher priority, it gets blocked until Entry2 finishes.

So there's only one case that is ill-defined - except that in a single
processor environment, one of them would have to have arrived there first.
In a multiple-processor environment, one starts to imagine true simultaneous
arrival - which I guess is going to get somehow arbitrated by the hardware.
(Unless the Indivisible Instruction finally meets the Unmaskable Interrupt!
:-) You'll probably at least have a deterministic answer - if not the answer
you wanted. Some other mechanism needs to decide the
same-priority-same-entry case. The priority inversion is a consequence of
entry priority having preference over task priority. Presumably, you're
design needed to consider that when you dreamed up the notion of
prioritizing the entries. (I think that case is in the ARM under the "I Weep
For You!" rule of task design. ;-)

Truly an interesting state of affairs, eh?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:8slD6.1888$D4.184457@www.newsranger.com...
> In article <vOkD6.1839$D4.178910@www.newsranger.com>, Ted Dennison says...
> Doh! I misread the conditionals. If waiting occurs, all the guards will be
> *open*. That should work fine (assuming the "or" is added, of course). If
> multiple rendezvous become active before this task gets around to
accepting one,
> I suppose the priority principle could be violated. But that's a pretty
marginal
> case.

Re: Multiple entry tasks

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]


"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans
le message news: 9bkevj$61k$1@nh.pace.co.uk...
> Sounds like you want some version of guarded entries in a select
statement.
> I have not attempted to do this before (kids: don't try this at home - we
> *are* trained professionals!), nor have I run this past a compiler (spank
me
> for this later if it doesn't work) but I *think* you want some version of
> the following:
>
> select
>     when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
>         accept Entry3 ;
>     when (Entry1'Count <= 0) =>
>         accept Entry2 ;
> or
>     accept Entry1;
> else
>     terminate;
> end select ;
>
This is wrong. Guards are evaluated only when the select is entered (unlike
POs), therefore if a task cancels its call (through timed entry call) while
the guards are being evaluated, you may end up in a situation of infinite
blocking.
The 'Count attribute should be used only with great care outside a PO. The
proper way of checking if a queue is empty is to use the else part of the
select statement. Therefore:

select
   accept Entry1;
else
   select
      accept Entry2;
   else
      select
         accept Entry1;
      or
         accept Entry2;
      or
         accept Entry3;
      or
         terminate;
      end select;
   end select;
end select;

Now, an exercise to see who is following. Those who attended an Adalog
training session are excluded from the competition :-)
1) Show that the sequence above exhibits a race condition
2) Show that the race condition is perfectly acceptable.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Multiple entry tasks

[Ted Dennison]

In article <9bksmp$ang$1@nh.pace.co.uk>, Marin David Condic says...
>
>If multiple rendezvous become active before you hit the select, I'd imagine
>that they would have to be queued according to the priority of the tasks
>that called the entries. It is a marginal case but probably worth thinking
>about for a minute anyway...

Hmmm. That's an interesting issue, and I suspect you are right, although the
language may require the select statement to make an arbitrary choice in this
circumstance. I'm not sure.

However, I was referring to the "priority" we are trying to encode into the 3
entries, not task priority. If we make a development policy that they are to be
the same (relatively), then I guess it would work out as you say. But in that
case, you might as well use the Priority_Queuing entry queuing policy, and not
even have to worry about guards at all.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Marin David Condic]

I've never played with Priority_Queuing - not an area I know enough to talk
about. However the name suggests that it might provide the answer for the
original problem. It depends on what you want to do, right? Otherwise, the
cascading selects suggested by you and JPR are probably a cleaner approach
than looking at guard conditions. (It corresponds nicely to the sort of
cascading if's that typically get created to handle non-tasking "priority"
issues & is probably more clear to the reader as to what is being done.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:udCD6.2834$D4.281263@www.newsranger.com...
> In article <9bksmp$ang$1@nh.pace.co.uk>, Marin David Condic says...
> However, I was referring to the "priority" we are trying to encode into
the 3
> entries, not task priority. If we make a development policy that they are
to be
> the same (relatively), then I guess it would work out as you say. But in
that
> case, you might as well use the Priority_Queuing entry queuing policy, and
not
> even have to worry about guards at all.
>

Re: Multiple entry tasks

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>
>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans
>le message news: 9bkevj$61k$1@nh.pace.co.uk...
>> select
>>     when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
>>         accept Entry3 ;
>>     when (Entry1'Count <= 0) =>
>>         accept Entry2 ;
>> or
>>     accept Entry1;
>> else
>>     terminate;
>> end select ;
>>
>This is wrong. Guards are evaluated only when the select is entered (unlike
>POs), therefore if a task cancels its call (through timed entry call) while
>the guards are being evaluated, you may end up in a situation of infinite
>blocking.

:-)

I made the same misreading as you on my first post. The guards will only close
if there is already an entry available on another branch. In that case the
higher priority entry will be immediately accepted, so there will be no blocking
at all. Thus there cannot be infinte blocking (execpt where intended :-) ).

I think the confusing part was that he used "<= 0" rather than "= 0". 'count
logically shouldn't ever go negative, but I guess he was trying to be safe
(perhaps there's some degenerate case about that in the LRM. I'd check it if
this were production code I was writing). I'd only expected to see a
two-character boolean of ">= 0", so that's what my brain reported. :-(

>select
>   accept Entry1;
>else
>   select
>      accept Entry2;
>   else
>      select
>         accept Entry1;
>      or
>         accept Entry2;
>      or
>         accept Entry3;
>      or
>         terminate;
>      end select;
>   end select;
>end select;
>
>1) Show that the sequence above exhibits a race condition
>2) Show that the race condition is perfectly acceptable.

Marin's code has the same "race condition". I also touched on that in a previous
post, but I'm always happy to go into more detail. :-)

Its quite possible for this server task to find no entries available and block
down in the inner select (or in Marin's case, block with all the guards open).
At that point, its quite possible for two separate tasks to become ready and
enqueue on Entry1 and Entry2 before this server task becomes active again. At
that point, the selection of which entry to accept will be based on factors
other than the priority we have tried to set up. However, I would consider such
"simultanious entries" to be a degenerate case which is really no worse than the
case where the server task accepts Entry_3 8 CPU cycles before a client requests
Entry_1. The duration of the inversion is practicly the same, and in both cases
Entry_1 is still properly queued, and will take priority over any other Entry_2s
and Entry_3s that arrive afterwards.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Marin David Condic]

Sorry. Force of habit. I generally code comparisons that avoid things like
"X = 0" out of fear that one day, somehow, X may be -1 and that still means
I want to take action based on nothing being there. (The 'Count attribute
returns Universal Integer - so negative numbers are at least within the
set - if not something that would actually get returned.) I've learned
especially to avoid that comparison on floating point numbers and there is
just a sort of paranoia in the back of my mind that wants to account for all
possible - and impossible - conditions. (Forgive us our paranoia, for we
know what we do!)

So if Entry1'Count is > 0, I definitely know I've got entries called - the
negation of that condition is "<=" and that accounts for everything. I
suppose I could have said "not (Entry1'Count > 0)" but that may have been
even more confusing!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:pPCD6.2928$D4.287059@www.newsranger.com...
> In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen
says...
> I think the confusing part was that he used "<= 0" rather than "= 0".
'count
> logically shouldn't ever go negative, but I guess he was trying to be safe
> (perhaps there's some degenerate case about that in the LRM. I'd check it
if
> this were production code I was writing). I'd only expected to see a
> two-character boolean of ">= 0", so that's what my brain reported. :-(
>

Re: Multiple entry tasks

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
pPCD6.2928$D4.287059@www.newsranger.com...
> In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen
says...
> >
> >
> >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit
dans
> >le message news: 9bkevj$61k$1@nh.pace.co.uk...
> >> select
> >>     when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
> >>         accept Entry3 ;
> >>     when (Entry1'Count <= 0) =>
> >>         accept Entry2 ;
> >> or
> >>     accept Entry1;
> >> else
> >>     terminate;
> >> end select ;
> >>
> >This is wrong. Guards are evaluated only when the select is entered
(unlike
> >POs), therefore if a task cancels its call (through timed entry call)
while
> >the guards are being evaluated, you may end up in a situation of infinite
> >blocking.
>
> :-)
>
> I made the same misreading as you on my first post. The guards will only
close
> if there is already an entry available on another branch. In that case the
> higher priority entry will be immediately accepted, so there will be no
blocking
> at all. Thus there cannot be infinte blocking (execpt where intended
:-) ).
I did the same misreading as you, but realized it before I posted. Now, you
misread my response ;-)
The sequence of events I was thinking of is the following:
Imagine that at the time you reach the select, there are calls for Entry2
and Entry3.
1) Evaluate the guard for Entry3. Since there is a call to Entry2, the guard
is closed
2) The call to Entry2 times out (it was a timed entry call).
3) Finish evaluating guards and block on select. You start waiting for
Entry2 and Entry1, although there is a call to Entry3 pending

If the logic of the caller is such that the next call to Entry1 or Entry2
will be issued only after Entry3 is serviced, you have dead-lock.

> I think the confusing part was that he used "<= 0" rather than "= 0".
Agreed. I was confused by that too.
And no, a 'Count cannot be negative. I always find this kind of "extra
security" damaging.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Multiple entry tasks

[Ted Dennison]

In article <9bmuo9$50h$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>The sequence of events I was thinking of is the following:
>2) The call to Entry2 times out (it was a timed entry call).

Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that the
runtime can change the state of the entry queues between the start of a select
statement and its decision to block or immediately accept an entry? In that
case, an "abort"ed task would hose him as well, right?

Generally I find that one has to be very carful about using timed or tenative
entry calls. As a general rule, you have to be damn sure that the server will at
some point sit and wait for your entry. If there's an "else" or "delay" clause
on the server's selective wait, you can get into a nasty case of livelock. Since
I generally need to use one of those clauses, I don't use timed or tenative
rendezvous very much.

Since I usually can't use them anyway, I don't think its much of a hardship to
prohibit timed rendezvous (and aborts) for clients of this server. What you gain
by doing this is an easier to maintain structure. With the way we did it, there
are two select branches that must be maintined in lock-step for all but the
highest-priority entry. That's not a big deal with our little toy example, as
there was no code in any of the branches. But for a complicated server with
loads of code in each branch, it could be a very big deal indeed.

Then again, its possible you might want to do different things if the entry was
accepted immediately vs. waited for. In that case what we did would be better.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Cascading the selects is an interesting mechanism. I'm not sure there is any
> answer that will be definitive. (Short of a language mod allowing one to
> prioritize entries?)

Under the Priority_Queueing policy, the entries are prioritized -- you
write the higher-priority accepts before the lower-priority ones.  Task
priorities take precedence over entry priorities, however.  I'm not
sure whether that's what the original poster wanted, but if all the
tasks are the same priority, then the order of the accept statements
determines the priority of the entries.

See RM-D.4(14).

- Bob

Re: Multiple entry tasks

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
sMGD6.3326$D4.330928@www.newsranger.com...
> Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that
the
> runtime can change the state of the entry queues between the start of a
select
> statement and its decision to block or immediately accept an entry? In
that
> case, an "abort"ed task would hose him as well, right?
The point in general is that the 'Count attribute returns the length of the
queue at the time it is called, but that it can increase or decrease (due to
timed entry calls or -you're right- abort) at any time. You can use it for
optimization purpose; for example, you might want to serve the longest queue
first. If there is a race condition, you may very rarely choose a queue that
is suboptimal by 1 - that's acceptable. But 'Count should not be used in an
all-or-nothing context.

> Generally I find that one has to be very carful about using timed or
tenative
> entry calls. As a general rule, you have to be damn sure that the server
will at
> some point sit and wait for your entry. If there's an "else" or "delay"
clause
> on the server's selective wait, you can get into a nasty case of livelock.
Since
> I generally need to use one of those clauses, I don't use timed or
tenative
> rendezvous very much.
Timed entry calls are very useful: a client may well want to do something
else if the server does not accept a request within a given time frame. You
might well argue that in some contexts, all calls must be timed (i.e. ensure
not infinite blocking).

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Multiple entry tasks

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

In article <9bpgnu$blc$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
>sMGD6.3326$D4.330928@www.newsranger.com...
>> some point sit and wait for your entry. If there's an "else" or "delay"
>> clause on the server's selective wait, you can get into a nasty case of 
>> livelock.
>Timed entry calls are very useful: a client may well want to do something

I'd agree that they can occasionally be useful. However, they are tricky and
fragile.

>else if the server does not accept a request within a given time frame. You
>might well argue that in some contexts, all calls must be timed (i.e. ensure
>not infinite blocking).

I'd argue that ensuring finite blocking for clients is the *server's*
responsibility. If the client is making an entry call, then presumably it
*needs* the server to do something. So if the client is going to time out of the
call, it will probably need to come back and make the same entry call later. If
the sever *still* won't service the call, the client is really infintiely
blocking, just with a loop instead of a single block.

To prevent dead/livelocks, its really best to think of tasks in terms of clients
and servers. Tasks making entry calls are clients, and accepting tasks are
servers. In this context tenative/timed entry calls are one way to allow a
server task to *also* be a client, without neglecting its own client(s).
However, for this to work, the server task called by your hybrid client-server
task's *must* at some point block (with no time-out) on the hybrid's entry. If
the server task has a timeout in its accept, there's a possiblity that the
timeouts of the two tasks will sync up, with the result being that they will
never (or very rarely) both be ready for the rendezvous. You might be able to
arrange this properly at first, but its quite common to discover the need to add
a timeout to a server's accept statment later in debugging or maintainence, and
there's no simple way to even see that there's a client somewhere in the system
that will be hosed by this. To top it off, the fix to the client is likely going
to have to be a redesign. Yeeeeach.

Typically if you find the need for a client-server task, it is much better to
just use another task or protected object to internally queue up requests to act
as a sort of client/server "gender-bender".

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
jL%D6.4582> I'd argue that ensuring finite blocking for clients is the
*server's*
> responsibility. If the client is making an entry call, then presumably it
> *needs* the server to do something. So if the client is going to time out
of the
> call, it will probably need to come back and make the same entry call
later. If
> the sever *still* won't service the call, the client is really infintiely
> blocking, just with a loop instead of a single block.
Interesting. I'd rather argue that in a client-server relationship, none of
the partners should trust the other one; each ensures its own security. It
is true that if the client times out, it will often come back later. Mut in
the meantime, it could ask on the console "Server not responding, try
again?", or try a different server, or just report a failure to upper levels
("connection lost"), or....

> To prevent dead/livelocks, its really best to think of tasks in terms of
clients
> and servers. Tasks making entry calls are clients, and accepting tasks are
> servers.
Agreed

>In this context tenative/timed entry calls are one way to allow a
> server task to *also* be a client, without neglecting its own client(s).
> However, for this to work, the server task called by your hybrid
client-server
> task's *must* at some point block (with no time-out) on the hybrid's
entry. If
> the server task has a timeout in its accept, there's a possiblity that the
> timeouts of the two tasks will sync up, with the result being that they
will
> never (or very rarely) both be ready for the rendezvous. You might be able
to
> arrange this properly at first, but its quite common to discover the need
to add
> a timeout to a server's accept statment later in debugging or
maintainence, and
> there's no simple way to even see that there's a client somewhere in the
system
> that will be hosed by this. To top it off, the fix to the client is likely
going
> to have to be a redesign. Yeeeeach.
That's one use of timed entry calls. I've met other ones...

> Typically if you find the need for a client-server task, it is much better
to
> just use another task or protected object to internally queue up requests
to act
> as a sort of client/server "gender-bender".
There once was a famous, though unpublished paper by P. Kruchten about the
"Sex of tasks", that neatly discussed "male" tasks (callers only), "female"
tasks (accepters only), "hermaphrodites tasks", one special case of it being
the "gender bender", etc. I don't think I have it anymore, nor that Philippe
is still listening c.l.a...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Multiple entry tasks

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

In article <9c0jot$cah$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>
>"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
>jL%D6.4582> I'd argue that ensuring finite blocking for clients is the
>> *server's* responsibility. If the client is making an entry call, then 
..
>Interesting. I'd rather argue that in a client-server relationship, none of
>the partners should trust the other one; each ensures its own security. It

If we were talking TCP/IP (or perhaps annex E), I'd probably agree with you. But
within the confines of a single program, I have to be able to count on my
servers working properly, just like I have to be able to count on my normal
subprograms working properly.

>>In this context tenative/timed entry calls are one way to allow a
>> server task to *also* be a client, without neglecting its own client(s).
>That's one use of timed entry calls. I've met other ones...

If we expand the concept of a "server" to include serving things other than Ada
tasks (eg: a display, a request queue, a device), I think this would cover just
about every use I can think of for timed entry calls.

>There once was a famous, though unpublished paper by P. Kruchten about the
>"Sex of tasks", that neatly discussed "male" tasks (callers only), "female"
>tasks (accepters only), "hermaphrodites tasks", one special case of it being
>the "gender bender", etc. I don't think I have it anymore, nor that Philippe
>is still listening c.l.a...

That's a shame. I'd be interested in what he had to say on the subject of
"hermaphrodite tasks". I think there's a few sets of situations where they can
be safe to use, if only one knows how to recognise the situation (and takes
pains to keep the conditions the same, even through later redesigns). But nearly
every time I've created one, I've regretted it.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Multiple entry tasks

[Lutz Donnerhacke]

* Robert A Duff wrote:
>Under the Priority_Queueing policy, the entries are prioritized -- you
>write the higher-priority accepts before the lower-priority ones.  Task
>priorities take precedence over entry priorities, however.  I'm not
>sure whether that's what the original poster wanted, but if all the
>tasks are the same priority, then the order of the accept statements
>determines the priority of the entries.

Thank you. That's the last one of a lot of very useful hints. I came to the
conclusion, that in every situation where a posting to cla is necessary the
code design is wrong anyway. So postings to cla are a sure sign of bad
programming ;-)