Re: Spin Lock sleep resolution
| От | Jeff Janes |
|---|---|
| Тема | Re: Spin Lock sleep resolution |
| Дата | |
| Msg-id | CAMkU=1xtP+3UWL6dg10rDRtMA28zy-9ujrOxNuST_r3zOdpNxg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Spin Lock sleep resolution (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Spin Lock sleep resolution
|
| Список | pgsql-hackers |
On Monday, April 1, 2013, Tom Lane wrote:
Jeff Janes <jeff.janes@gmail.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
Вложения
В списке pgsql-hackers по дате отправления: