Oh, thanks. That makes sense.
> Bruce Momjian <[EMAIL PROTECTED]> 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 queryin
Bruce Momjian <[EMAIL PROTECTED]> 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^HCompa
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
> 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,
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 q
* Bruce Momjian <[EMAIL PROTECTED]> [010101 23:59] wrote:
> > Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > > One trick that may help is calling sched_yield(2) on a lock miss,
> > > it's a POSIX call and quite new so you'd need a 'configure' test
> > > for it.
> >
> > The author of the current
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > One trick that may help is calling sched_yield(2) on a lock miss,
> > it's a POSIX call and quite new so you'd need a 'configure' test
> > for it.
>
> The author of the current s_lock code seems to have thought that
> select() with a zero delay w
> > Actually, one slocks are held
> > longer than anothers - probably we should use different delays...
>
> I don't understand the last remark. Are you proposing to mix some
> random numbers into the delays?
No, use different s_spincycle-s for different slocks.
Vadim
On Fri, Dec 29, 2000 at 10:54:00AM -0800, Mikheev, Vadim wrote:
> > > The code is based on some odd assumptions. A select() with 0 delay
> > > returns immediately unless there is an interrupt during its
> > > (very short!) time in kernel space.
> >
> > Yeah, I've wondered whether the 0 entries
> > The code is based on some odd assumptions. A select() with 0 delay
> > returns immediately unless there is an interrupt during its
> > (very short!) time in kernel space.
>
> Yeah, I've wondered whether the 0 entries in s_spincycle[]
> shouldn't be 1. The code author evidently expected s
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> One trick that may help is calling sched_yield(2) on a lock miss,
> it's a POSIX call and quite new so you'd need a 'configure' test
> for it.
The author of the current s_lock code seems to have thought that
select() with a zero delay would do the eq
* Tom Lane <[EMAIL PROTECTED]> [001228 14:25] wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > I wonder about the advisability of using spinlocks in user-level code
> > which might be swapped out any time.
>
> The reason we use spinlocks is that we expect the lock to succeed (not
> block) t
[EMAIL PROTECTED] (Nathan Myers) writes:
> On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
>> The reason we use spinlocks is that we expect the lock to succeed (not
>> block) the majority of the time, and we want the code to fall through
>> as quickly as possible in that case. In partic
On Thu, Dec 28, 2000 at 05:26:23PM -0600, Dominic J. Eidson wrote:
> On Thu, 28 Dec 2000, Nathan Myers wrote:
>
> > The code is based on some odd assumptions. A select() with 0 delay
> > returns immediately unless there is an interrupt during its (very short!)
>
> If you look closely, it's a
On Thu, Dec 28, 2000 at 05:12:22PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > I wonder about the advisability of using spinlocks in user-level code
> > which might be swapped out any time.
>
> The reason we use spinlocks is that we expect the lock to succeed (not
> blo
[EMAIL PROTECTED] (Nathan Myers) writes:
> I wonder about the advisability of using spinlocks in user-level code
> which might be swapped out any time.
The reason we use spinlocks is that we expect the lock to succeed (not
block) the majority of the time, and we want the code to fall through
as
On Thu, Dec 28, 2000 at 03:54:50PM -0500, Tom Lane wrote:
> I have been digging into the observed failure
>
> FATAL: Checkpoint lock is busy while data base is shutting down
>
> on some Alpha machines. It apparently doesn't happen on all Alphas,
> but it's quite reproducible on some of them.
>
17 matches
Mail list logo
