Re: Spin Lock sleep resolution

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spin Lock sleep resolution
Date: 2013-04-02 16:01:36
Message-ID: CAMkU=1xtP+3UWL6dg10rDRtMA28zy-9ujrOxNuST_r3zOdpNxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday, April 1, 2013, Tom Lane wrote:

> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> > The problem is that the state is maintained only to an integer number of
> > milliseconds starting at 1, so it can take a number of attempts for the
> > random increment to jump from 1 to 2, and then from 2 to 3.
>
> Hm ... fair point, if you assume that the underlying OS has a sleep
> resolution finer than 1ms. Otherwise it would not matter.

Let's say you get a long stretch of increments that are all a ratio of <1.5
fold, for simplicity let's say they are all 1.3 fold. When you do
intermediate truncations of the state variable, it never progresses at all.

perl -le '$foo=1; foreach (1..10) {$foo*=1.3; print int $foo}'

perl -le '$foo=1; foreach (1..10) {$foo*=1.3; $foo=int $foo; print int
$foo}'

Obviously the true stochastic case is not quite that stark.

> No patch seen here ...
>

Sorry. I triple checked that the patch was there, but it seems like if you
save a draft with an attachment, when you come back later to finish and
send it, the attachment may not be there anymore. The Gmail Offline teams
still has a ways to go. Hopefully it is actually there this time.

Cheers,

Jeff

Attachment Content-Type Size
spin_delay_microsecond_v1.patch application/octet-stream 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-04-02 16:03:10 Re: in-catalog Extension Scripts and Control parameters (templates?)
Previous Message David E. Wheeler 2013-04-02 15:59:49 Re: citext like searches using index