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

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

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: 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 21:44:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jun 26, 2012 at 01:46:06PM -0500, Merlin Moncure wrote:
> Well, that would introduce a backend dependency on pthreads, which is
> unpleasant.  Also you'd need to feature test via
> _POSIX_THREAD_PROCESS_SHARED to make sure you can mutex between
> processes (and configure your mutexes as such when you do).  There are
> probably other reasons why this can't be done, but I personally don' t
> klnow of any.

And then you have fabulous things like:
(OSX defines _POSIX_THREAD_PROCESS_SHARED but does not actually support

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.

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> 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: Daniel FarinaDate: 2012-06-26 21:45:52
Subject: Re: pg_terminate_backend for same-role
Previous:From: Josh BerkusDate: 2012-06-26 21:44:13
Subject: Re: Posix Shared Mem patch

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