Re: Multiple entry tasks

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

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.