[krbdev.mit.edu #7884] profile writes may not be immediately detected within same process

[Greg Hudson via RT]

The attached test program, run with the pathname of an empty file, does 
the following:

1. Open prof1 to a given filename
2. Open prof2 to the same filename, add a relation, and close it
3. Open prof3 to the same filename and try to read it

If steps 2 and 3 occur within the same clock second, step 3 won't see 
the change from step 2.  What happens under the covers is:

1. When prof1 is created, we read the file and populate g_shared_trees 
with a prf_data_t object for the filename, with refcount 1.  The 
last_stat field of the prf_data_t object is set to the current time.

2a. When prof2 is created, we reuse the same prf_data_t object, so it 
now has refcount 2.  If the clock has advanced from step 1, we re-stat 
the file, re-read it if it changed, and set last_stat to the current 
time.

2b. When we add a relation to prof2, prof_set.c:rw_setup() is invoked.  
This function creates a fresh prf_data_t object which is not part of 
g_shared_trees, and alters prof2 to point to the new object.  The old 
shared object is dereferenced, but because prof1 is still open, its 
refcount is still positive, so it is not destroyed and still has the 
current time as last_stat.

2c. When prof2 is released, its contents are written out to the file and 
the new private prf_data_t object is destroyed.  The shared object for 
the file in g_shared_trees is not touched in this step.

3. When prof3 is created, we reuse the prf_data_t object from step 1.  
Since its last_stat field still has the current time from step 2a, we do 
not check to see if the file was updated, and therefore do not read the 
new contents with the relation added in step 2b.