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