| From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
| Subject: | Re: LWLock contention: I think I understand the problem |
| Date: | 2001-12-29 19:24:02 |
| Message-ID: | 3C2E1852.F2E6DF82@fourpalms.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-odbc |
...
> It would seem, therefore, that lwlock.c's behavior of immediately
> granting the lock to released waiters is not such a good idea after all.
> Perhaps we should release waiters but NOT grant them the lock; when they
> get to run, they have to loop back, try to get the lock, and possibly go
> back to sleep if they fail. This apparent waste of cycles is actually
> beneficial because it saves context swaps overall.
Hmm. Seems reasonable. In some likely scenerios, it would seem that the
waiters *could* grab the lock when they are next scheduled, since the
current locker would have finished at least one
grab/release/grab/release cycle in the meantime.
How hard will it be to try this out?
- Thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-12-29 19:35:49 | Re: LWLock contention: I think I understand the problem |
| Previous Message | Tom Lane | 2001-12-29 19:10:43 | LWLock contention: I think I understand the problem |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-12-29 19:35:49 | Re: LWLock contention: I think I understand the problem |
| Previous Message | Tom Lane | 2001-12-29 19:10:43 | LWLock contention: I think I understand the problem |