Skip site navigation (1) Skip section navigation (2)

Re: spinlock->pthread_mutex : real world results

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Nils Goroll <slink(at)schokola(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlock->pthread_mutex : real world results
Date: 2012-08-06 21:25:20
Message-ID: 20120806212520.GB20088@svana.org (view raw or flat)
Thread:
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(at)svana(dot)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

In response to

pgsql-hackers by date

Next:From: Nils GorollDate: 2012-08-06 22:10:02
Subject: Re: spinlock->pthread_mutex : real world results
Previous:From: Robert HaasDate: 2012-08-06 19:08:38
Subject: Re: redundant message?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group