Re: Assuming that TAS() will succeed the first time is verboten

Oh, thanks. That makes sense.

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> 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?
>
> An ordinary write would be re-executed and would succeed after the
> page fault. stq_c is different, because it's only supposed to succeed
> if the processor has managed to hold an access lock on the target
> address continuously since the ldq_l. It would be very bad form to try
> to hold the lock during a page fault. (stq_c will also fail if the
> processor is interrupted between ldq_l and stq_c, so occasional failures
> are to be expected. What was surprising me was the consistency of the
> failure pattern.)
>
> See the Alpha Architecture Manual if you really want to discuss this.
>
> regards, tom lane
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026