sc268116@seas.gwu.edu (Kavosh Soltani) (04/26/91)
After reading the ISIS manual and technical papers (TRs), I am still not
completely clear on how ISIS exactly works. Does any of the ISIS gurus out
there know the answer to the following:
1) I know that monitors and watches are implemented as tasks by ISIS.
But, where is the guarantee that they work?
Example:
If we have three user tasks, while the first is running, a value
monitored is changed. As described in the manual, the monitor is not
triggered until all three tasks are completed. But in the meantime
the value may change again or something else may happen...
Am I missing something?
2) Original broadcast system of ISIS uses a sequencer and Coordinator-
Cohort mechanism to implement its virtual synchronization and
atomicity. But how is the original algorithm implemented to gurantee
these features for the protocol itself?
Does ISIS use timeouts, some form or token passing, or what to
implement the protocol itself?
Thank you,ken@CS.Cornell.EDU (Ken Birman) (04/27/91)
In article <3128@sparko.gwu.edu> sc268116@seas.gwu.edu (Kavosh Soltani) writes: >After reading the ISIS manual and technical papers (TRs), I am still not >completely clear on how ISIS exactly works. Does any of the ISIS gurus out >there know the answer to the following: > > 1) I know that monitors and watches are implemented as tasks by ISIS. > But, where is the guarantee that they work? > > Example: > If we have three user tasks, while the first is running, a value > monitored is changed. As described in the manual, the monitor is not > triggered until all three tasks are completed. But in the meantime > the value may change again or something else may happen... > > Am I missing something? Well, actually, the monitor does trigger but the new task goes on the end of the task runqueue. It won't run until the three tasks have all blocked, but it WILL run before any new message is accepted from the outside world. Since ISIS monitors are usually triggered by events from the outside, this generally means that the condition will still hold when the monitor routine gets to exit -- i.e. for a group watch monitor or something of that sort. An example that could "break" in the way that worries you would be a call to isis_input() that causes a task to be created, but such that some other task reads the input before the task executes. This would leave the new task active and hence it would probably do a blocking read, leaving your program hung until the next input. But, this would also be a remarkably bad software architecture. > > 2) Original broadcast system of ISIS uses a sequencer and Coordinator- > Cohort mechanism to implement its virtual synchronization and > atomicity. But how is the original algorithm implemented to gurantee > these features for the protocol itself? > > Does ISIS use timeouts, some form or token passing, or what to > implement the protocol itself? > You have an overly simplified mental model of how the system is structured. The ISIS protocols don't use a sequencer or a coordinator cohort scheme in the protocols themselves. The original protocols are described in great detail in a TOCS paper that appeared in 1987; the more recent protocols in the paper that you can copy from ftp.cs.cornell.edu ("Lightweight Causal and Atomic Group Multicast"). The scheme is, like many real protocols, considerably more complicated than you might have expected. But, on the positive side, we have rigorous correctness proofs and the performance is excellant, so complexity need not imply inefficiency. I hope this helps. If you have specific questions after reading the papers, I'll try and respond to them in more detail. (At the level of ISIS that interests you, I wrote most of the code in the current system; Tommy Joseph did a lot of the code in the older system but we worked closely together on that). -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428