Re: spinlock->pthread_mutex : real world results
Martijn van Oosterhout <kleptog@svana.org>
From: Martijn van Oosterhout <kleptog@svana.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nils Goroll <slink@schokola.de>, Jeff Janes <jeff.janes@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Merlin Moncure <mmoncure@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-08-06T21:25:20Z
Lists: pgsql-hackers
On Mon, Aug 06, 2012 at 08:54:11AM -0400, Robert Haas wrote: > 2. Should we be modifying our spinlock implementation on Linux to use > futexes rather than pulling pthreads into the mix? > > Anyone have data on the first point, or opinions on the second one? I'm not sure whether pthreads is such a thick layer. Or are you referring to the fact that you don't want to link against the library at all? If we've found a situation where our locks work better than the ones in pthreads than either (a) we're doing something wrong or (b) the pthreads implementation could do with improvement. In either case it might be worth some investigation. If we can improve the standard pthreads implementation everybody wins. BTW, I read that some *BSDs have futex implementations (to emulate linux), it might be an idea to see where they're going. e.g. http://osdir.com/ml/os.dragonfly-bsd.kernel/2003-10/msg00232.html Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce sinval synchronization overhead.
- b4fbe392f8ff 9.2.0 cited