ken@gvax.cs.cornell.edu (Ken Birman) (09/11/90)
>From: aprakash@dost.eecs.umich.edu (Atul Prakash) >We are having a problem in running a program under v2.1 that was >not there in 2.0. I am not sure if the bug is with >v2.0, with v2.1 or with the manual. The thing is that at one place >in our code, we are making a bcast in a loop, checking whether isis_nsent is >same as isis_nreplies (similar to the code on p.20 in Time-card service >example in the manual). The clients in our case always >use nullreply(msgptr) to reply >to the message. It seems to me that for our program, in v2.0 nullreply was >updating the variable isis_nreplies, but in v2.1 it is not. Therefore, >our code, which use to successfully exit the loop in v2.0, now >repeatedly executes the bcast loop. My understanding is that isis_nreplies >includes null replies -- only failures before >or during sending of a reply fail to update isis_nreplies -- but that >does not seem to be happening. If you use nullreply() isis_nsent will always be greater than isis_nreplies by the number of null replies sent. I.e., isis_nreplies = isis_nsent - # nullreplies - # failed The manual has been corrected to use a different solution in the chapter that used to recommend this approach. The problem has nothing to do with the version of ISIS you run. We also changed the manual to add a short discussion of why the old scheme was a bad idea (specifically, it is a bad idea to have the client "know" what the server does) Sorry if this confused you! It confused a lot of people. In ISIS V3.0, we are thinking of adding additional variables isis_nfailed isis_nnull the system actually knows the values of these but doesn't report them. (Adding isis_nnull into isis_nreplies wouldn't be the right way to go because then you wouldn't know how long the reply vector turned out to be). Apropos, people have pointed out that the global variables isis_nsent, etc, pose a problem under pre-emptive threads packages. Currently, these are protected by the isis mutex lock, but we could probably make them into subroutine calls, i.e. isis_current_task()->task_isis_nreplies if necessary. So, code written to use the current scheme will probably be supported even if we make ISIS much more concurrent in the future. ... Ken