From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reduce ProcArrayLock contention |
Date: | 2015-08-04 15:51:20 |
Message-ID: | 20150804155120.GA32119@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-08-04 11:43:45 -0400, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 11:33 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Actually by far not all system calls are full barriers?
>
> How do we know which ones are and which ones are not?
Good question. Reading the source code of all implementations I suppose
:(
E.g. gettimeofday()/clock_gettime(), getpid() on linux aren't
barriers.
> I can't believe PGSemaphoreUnlock isn't a barrier. That would be cruel.
Yea, I think that's a pretty safe bet. I mean even if you'd implement it
locklessly in the kernel, that'd still employ significant enough
barriers/atomic ops itself.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-04 15:51:41 | Re: upgrade failure from 9.5 to head |
Previous Message | Amit Kapila | 2015-08-04 15:50:20 | Re: Reduce ProcArrayLock contention |