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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assuming that TAS() will succeed the first time is verboten
Date: 2001-01-09 03:15:30
Message-ID: 200101090315.WAA10993@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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?

--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Myers 2001-01-09 03:41:46 Re: Assuming that TAS() will succeed the first time is verboten
Previous Message Tatsuo Ishii 2001-01-09 02:26:30 README.mb