"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Anyway I don't object if it bothers you -:)
> But please do not use S_LOCK - as you see WAL code try to do other
> things if slock of "primary interest" is busy.
In some places, yes. But I also saw a number of places where S_LOCK is
sufficient, and I think it's clearer to code that way whenever there's
not useful work to do before acquiring the lock. For example, is
if (updrqst)
{
unsigned i = 0;
for (;;)
{
if (!TAS(&(XLogCtl->info_lck)))
{
if (XLByteLT(XLogCtl->LgwrRqst.Write, LgwrRqst.Write))
XLogCtl->LgwrRqst.Write = LgwrRqst.Write;
S_UNLOCK(&(XLogCtl->info_lck));
break;
}
s_lock_sleep(i++);
}
}
really better than
if (updrqst)
{
S_LOCK(&(XLogCtl->info_lck));
if (XLByteLT(XLogCtl->LgwrRqst.Write, LgwrRqst.Write))
XLogCtl->LgwrRqst.Write = LgwrRqst.Write;
S_UNLOCK(&(XLogCtl->info_lck));
}
? I don't think so...
What I'm thinking of doing for the places where there is useful work
to do while waiting is
spins = 0;
while (TAS(lock))
{
/* do useful work here */
S_LOCK_SLEEP(spins++);
}
where S_LOCK_SLEEP() expands to do the same things as the body of the
existing loop in s_lock().
regards, tom lane
