The whole thing is not a race condition. The effect of just missing an
event and having to wait for another cycle is just the way
synchronization works.
If it is true that a newly created file is visible after the first write
and before it is closed, then that creates a race condition.
The "race" is to finish writing to the file before reading the file
finishes - due to the file being "discovered" before it all writes complete.
That is also the problem with just creating a file that is used to
provide the html page containing the "refresh" and then just replacing
it with the real file containing all the data. That is if the "refresh"
occurs in the middle of writing the file and the file is read before the
write completes.
The way to solve the "race" is to not allow the file to be read until
all writes are completed. One way is through file locking.
But there are other ways.
One way is to know how much time is required from the time the
file can be first discovered until the all the writes complete. Then
delay the first read after the file discovery by that much time. This
is generally the way race conditions are solved in hardware because the
delays are quite predictable and small. But not all that great for
software because the delays are not so predictable.
Another is to use a different "trigger" that the creation of the
file. If the Session State is used, then it must be semaphored or locked.
A different file could be used that is only created but not
read or written. But the cost of creating the different file (and
deleting it later) needs to be compared to the cost of file locking (and
waiting to acquired the lock if it is held by another)
And I'm sure there are many other ways...
Doug
