On Mon, Jan 08, 2001 at 10:15:30PM -0500, Bruce Momjian wrote:
> > One last followup on that bizarreness about shutdown's checkpoint
> > failing on Alpha platforms ---
> >
> > After changing the checkpoint code to loop, rather than assuming TAS()
> > must succeed the first time, I noticed that it always looped exactly
> > once. This didn't make sense to me at the time, but after querying some
> > Alpha experts at DEC^H^H^HCompaq, it does now. If a new process's first
> > write to a shared memory page is a stq_c, that stq_c is guaranteed to
> > fail (at least on Tru64 Unix), because it will page fault. The shared
> > memory page is inherited read-only and is converted to read-write on
> > first fault. This doesn't seem really necessary, but I suppose it's
> > done to share code with the copy-on-write case for non-shared pages
> > that are inherited via fork().
>
> This seems quite bizarre. Why would the process fail on the write, and
> not just pause and wait for the fault to bring in the page? Doesn't the
> CPU halt the instruction to fetch in the page and restart the
> instruction?
This is normal, although non-intuitive. (Good detective work, Tom.)
The definition of load-locked/store-conditional says that if there's
been an interrupt or trap (e.g. page fault) since the load-locked
instruction executed, the store-conditional instruction fails. That
way you don't overwrite something that might have been written by
another process that ran during the interval before you got the CPU
again.
Thus, the instruction does get restarted, but the lock has been
(correctly) cleared, resulting in the need for failure/retry. It's
not a performance issue, because it only happens once per process.
Think of it as part of the cost of forking.
Nathan Myers
ncm@zembu.com