From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Spin Lock sleep resolution |
Date: | 2013-04-02 05:40:40 |
Message-ID: | CAGTBQpY3gspgQ3jQB-q9Ck9UicNJpC_4GN6mGEtNKX2di1WWEg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 2, 2013 at 1:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
I would guess it does matter for the cumulative error when re-sleeping
several times.
In any case, the resolution is limited on tick-based kernels, which
are few nowadays. However, I've found evidence[0] that FreeBSD is
still on that boat.
[0] http://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012423.html
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-04-02 05:53:34 | Re: Page replacement algorithm in buffer cache |
Previous Message | Atri Sharma | 2013-04-02 05:08:20 | Re: Page replacement algorithm in buffer cache |