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

Re: why roll-your-own s_lock? / improving scalability

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Nils Goroll <slink(at)schokola(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: why roll-your-own s_lock? / improving scalability
Date: 2012-06-26 22:12:19
Message-ID: 14481.1340748739@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> And then you have fabulous things like:
> https://git.reviewboard.kde.org/r/102145/
> (OSX defines _POSIX_THREAD_PROCESS_SHARED but does not actually support
> it.)

> Seems not very well tested in any case.

> It might be worthwhile testing futexes on Linux though, they are
> specifically supported on any kind of shared memory (shm/mmap/fork/etc)
> and quite well tested.

Yeah, a Linux-specific replacement of spinlocks with futexes seems like
a lot safer idea than "let's rely on posix mutexes everywhere".  It's
still unproven whether it'd be an improvement, but you could expect to
prove it one way or the other with a well-defined amount of testing.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Daniel FarinaDate: 2012-06-26 22:12:41
Subject: Re: Posix Shared Mem patch
Previous:From: Kevin GrittnerDate: 2012-06-26 22:05:27
Subject: Re: Catalog/Metadata consistency during changeset extraction from wal

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