James Browning said: > I had this foolish notion that one could set up an extra storage space and an > indicator. ... > 3. client atomically change the indicator to that space. ... > Which seems too simple not to be in use. So, it must not work generally.
That works as long as the reader (server) finishes using the data in that slot before the writer (client) updates that slot again. The more general case is a ring of N slots and a pointer/index to the one with the most recent data. In our case, 2 slots probably works all of the time. But maybe not quite all. It's probably simpler and cleaner in the long run to write the code to do something known to be correct than it is to keep discussing what happens if it doesn't work. This is similar to the handoff problem with SHM -- one writer, several readers if you run a monitor program in parallel with ntpd. The complication with SHM is that the reader and writer can be in separate processes and we haven't come up with a clean way to initialize locks and/or recover from crashes. The best solution I know of for SHM is 2 counters. Call them X and Y. The writer bumps X, updates the data, then bumps Y. The reader grabs Y, grabs the data, grabs X, then compares the grabbed copies of X and Y. If they are the same the data is valid. If not, try again. The important point is that the reader and writer access X and Y in the opposite order. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
