Re: spinlocks on HP-UX
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2011-08-29T15:47:48Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Typo fixes.
- 0510b62d9115 9.2.0 cited
On Mon, Aug 29, 2011 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Aug 29, 2011 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> IIUC, this is basically total nonsense. > >>> It could maybe be rewritten for more clarity, but it's far from being >>> nonsense. The responsibility for having an actual hardware memory fence >>> instruction lies with the author of the TAS macro. > >> Right... but the comment implies that you probably don't need one, and >> doesn't even mention that you MIGHT need one. > > I think maybe we need to split it into two paragraphs, one addressing > the TAS author and the other for the TAS user. I'll have a go at that. OK. >> I think optimizing spinlocks for machines with only a few CPUs is >> probably pointless. Based on what I've seen so far, spinlock >> contention even at 16 CPUs is negligible pretty much no matter what >> you do. > > We did find significant differences several years ago, testing on > machines that probably had no more than four cores; that's where the > existing comments in s_lock.h came from. Whether those tests are > still relevant for today's source code is not obvious though. Hmm, OK. I guess if you want to put energy into it, I'm not going to complain too much... just not sure it's the best use of time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company