🚀 go-pugleaf

>If there are _any_ threads that modify the variable, then all threads
>must cooperate to ensure that it is only modified when none are also
>trying to read it.

Exactly.

>
>Otherwise, the writing thread may have partially updated it when a
>reading thread attempts to read it. If it's a primitive, and you only
>have a single processor machine with no ability to actually execute more
>than one thread at a time, then I don't think you will see thread
>switching in the middle of the write.
>
>However, some of us already have multi-processor PCs, and also
>hyperthreading and multi-core CPUs will be increasingly common in the
>near future. With these, I think even a primitive is no longer safe.
>

If the question what reading thread will see ("variable before" 
or "variable after") it is not important. Windows is not 
"real-time" system and beside this dispatch threads (even for 
multi processor) in the way that Microsoft guys know only.
Really if another threads will work in system (it is normally 
thing) that will do some another work it will be absolutely 
impossible when and what value reading thread MUST read - 
value before changing or after.

For example, thread must read value in 10:00 but just before 
this time dispatcher pass control to another thread. So 
variable was read in 10:00:00.20 but another thread made 
changes in 10:00:00.10. If first thread read it in time 
(10:00:00.00) it read before value but in above case it 
read after value. The critical section can't help in this case.

But if value can change during some period of time... Oh, in this case 
reading thread may listen or watch all its time carefully (via continuos 
enters in critical section or semaphor) for changing.
Vladimir.