Spinlock backoff algorithm - Mailing list pgsql-hackers

From Magne Mæhre
Subject Spinlock backoff algorithm
Date
Msg-id 473AC13B.1060008@sun.com
Whole thread Raw
Responses Re: Spinlock backoff algorithm  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Re: Spinlock backoff algorithm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I was playing with a Nevada server and noticed a rush on the FPU
(the Nevada has a single shared FPU for its 32 threads).
Looking at the spinlock code, I found :
 cur_delay += (int) (cur_delay * ((double) random() / (double) MAX_RANDOM_VALUE) + 0.5);

I understand the reasoning for the backoff (as of the discussion on
2003-08-05), but is there any particular reason for using floating
point operations here ?   Maybe a modulo would be just as good (or
better since it doesn't involve the FPU) ?

Something like:   cur_delay  +=  random() % (cur_delay + 1) ;


--Magne


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: LDC - Load Distributed Checkpoints with PG8.3b2 on Solaris
Next
From: Zdenek Kotala
Date:
Subject: Re: Spinlock backoff algorithm