1

I am studying for an exam and am having a difficult time understanding Rendezvous. Here's an example I'm looking a

While(1) {
 select{
  when a == TRUE :
   accept A() {f1; b=FALSE}
  when b == TRUE :
   accept B() {f2; a=FALSE}
  else {a=true; b=true}
 }
}

The following calls arrive in the given order: A(), B(), B(), A(), A(), B()

In which order will the calls be accepted? And can caller of A or B starve?

I'd really appreciate any help. Thanks in advance.

JTai
  • 11
  • 1
  • 2
  • 1
    Even if this *were* Ada code (it is not. Ada doesn't use curly braces, or a `==` operator, and the language is case-insensitive, so `a` and `A` would be the same thing), the way I'm reading it I don't think the question could be answered without knowing the initial state of your two boolean flags (guards, I'm guessing). Are you sure this isn't something like Concurrent C? – T.E.D. Jan 26 '11 at 15:26

3 Answers3

6

That's not Ada. At all.

For some guidance on tasking with actual Ada read Chapter 14 of Ada Distilled.

And to be honest, if you didn't recognize your example as not Ada, you probably ought to start with Chapter 1.

Marc C
  • 8,664
  • 1
  • 24
  • 29
4

Going with the logic of your problem rather than the syntax, I think the answer is 'it all depends'.

The task that's running this loop (call it Server) is in a busy loop (most times round the loop, it'll end up setting A := True; B := True;). This could use up all your CPU and starve the other tasks out.

Assuming that doesn't happen and you have 2 client tasks A_Caller and B_Caller which have higher priority than Server and call their entries relatively infrequently, then you might get

  1. A_Caller and B_Caller both run and call their respective entries.
  2. Server enters the select and finds both guards open and the entries called; it chooses to accept A (it could have chosen B). The guard B is closed.
  3. Next time round the loop, guard A is open but there is no caller; guard B is closed; the else part is chosen, so guard B is opened.
  4. Next time round the loop, Server accepts B; guard A is closed.
  5. Next time round the loop, guard B is open but there is no caller; the else part is chosen, so guard A is opened.
  6. Next time round the loop, both guards are open but there is no caller, so the else part is chosen again and away we spin.

Obviously the exact sequence followed will depend on when the entry calls arrive with respect to Server's loop. Assuming the entry calls in your question happen a second apart, the entries will be accepted in the order called.

I don't think you can get starvation unless one of the callers is running sufficiently frequently that it's called its entry again before Server has got back round its loop. It would be hard to get this to happen under a general-purpose OS.

Simon Wright
  • 25,108
  • 2
  • 35
  • 62
2

This does not look like ada syntax, Perhaps you could repost with ada code? Meanwhile i refer you to: http://en.wikibooks.org/wiki/Ada_Programming/Tasking#Rendezvous

NWS
  • 3,080
  • 1
  • 19
  • 34