Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-25 Thread Robert Haas
On Wed, Sep 24, 2014 at 2:45 PM, Andres Freund wrote: > On 2014-09-09 17:54:03 -0400, Robert Haas wrote: >> So, that's committed, then. I think we should pick something that uses >> spinlocks and is likely to fail spectacularly if we haven't got this >> totally right yet, and de-volatilize it. An

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-24 Thread Andres Freund
On 2014-09-09 17:54:03 -0400, Robert Haas wrote: > So, that's committed, then. I think we should pick something that uses > spinlocks and is likely to fail spectacularly if we haven't got this > totally right yet, and de-volatilize it. And then watch to see what > turns red in the buildfarm and/or

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-10 Thread Robert Haas
On Tue, Sep 9, 2014 at 6:00 PM, Andres Freund wrote: > On 2014-09-09 17:54:03 -0400, Robert Haas wrote: >> So, that's committed, then. > > Yay, finally. > >> I think we should pick something that uses >> spinlocks and is likely to fail spectacularly if we haven't got this >> totally right yet, and

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Andres Freund
On 2014-09-09 17:54:03 -0400, Robert Haas wrote: > So, that's committed, then. Yay, finally. > I think we should pick something that uses > spinlocks and is likely to fail spectacularly if we haven't got this > totally right yet, and de-volatilize it. And then watch to see what > turns red in th

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Robert Haas
On Tue, Sep 9, 2014 at 5:32 PM, Andres Freund wrote: > On 2014-09-09 17:30:44 -0400, Robert Haas wrote: >> On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote: >> > On 2014-09-09 13:52:40 -0400, Robert Haas wrote: >> >> I had forgotten that it needed an update. Thanks for the reminder. >> >> H

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Andres Freund
On 2014-09-09 17:30:44 -0400, Robert Haas wrote: > On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote: > > On 2014-09-09 13:52:40 -0400, Robert Haas wrote: > >> I had forgotten that it needed an update. Thanks for the reminder. > >> Here's v2. > > > > I've attached a incremental patch fixing m

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Robert Haas
On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund wrote: > On 2014-09-09 13:52:40 -0400, Robert Haas wrote: >> I had forgotten that it needed an update. Thanks for the reminder. Here's >> v2. > > I've attached a incremental patch fixing minor gripes. Other than that I > think you can go ahead with

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Andres Freund
On 2014-09-09 13:52:40 -0400, Robert Haas wrote: > I had forgotten that it needed an update. Thanks for the reminder. Here's > v2. I've attached a incremental patch fixing minor gripes. Other than that I think you can go ahead with this once the buildfarm accepts the sparc fixes (man, those mac

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Robert Haas
On Mon, Sep 8, 2014 at 7:10 PM, Andres Freund wrote: >> This has been pending for almost two months now and, at your request, >> my patch to make spinlocks act as compiler barriers is waiting behind >> it. Can we please get this moving again soon, or can I commit that >> patch and you can fix thi

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-09 Thread Andres Freund
On 2014-09-04 08:18:37 -0400, Robert Haas wrote: > On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote: > > On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund > > wrote: > >>> > If you want to do that, it's fine with me. What I would do is: > >>> > > >>> > - Back-patch the addition of the sparcv8+ st

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Tom Lane
Robert Haas writes: > But what we're talking about here is a bug fix for Sparc. And surely > we ought to back-patch that. Ah. OK, no objection. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Bruce Momjian
On Mon, Sep 8, 2014 at 10:08:04AM -0400, Robert Haas wrote: > On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote: > > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: > >> Yes. I plan to push the patch this weekend. Sorry for the delay. > > > > I'm about to push this. Is it ok to first push it

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Robert Haas
On Mon, Sep 8, 2014 at 10:07 AM, Tom Lane wrote: > It makes for a cleaner commit history if you push concurrently into > all the branches you intend to patch. That also gives more buildfarm > runs, which seems like a good thing for this sort of patch. > > That is, assuming that we ought to backpa

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Tom Lane
Andres Freund writes: > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: >> Yes. I plan to push the patch this weekend. Sorry for the delay. > I'm about to push this. Is it ok to first push it to master and only > backpatch once a couple buildfarm cycles haven't complained? It makes for a clea

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Robert Haas
On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote: > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: >> Yes. I plan to push the patch this weekend. Sorry for the delay. > > I'm about to push this. Is it ok to first push it to master and only > backpatch once a couple buildfarm cycles haven't

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-08 Thread Andres Freund
On 2014-09-04 14:19:47 +0200, Andres Freund wrote: > Yes. I plan to push the patch this weekend. Sorry for the delay. I'm about to push this. Is it ok to first push it to master and only backpatch once a couple buildfarm cycles haven't complained? Greetings, Andres Freund -- Andres Freund

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-04 Thread Andres Freund
On September 4, 2014 2:18:37 PM CEST, Robert Haas wrote: >On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas >wrote: >> On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund > wrote: > If you want to do that, it's fine with me. What I would do is: > > - Back-patch the addition of the sparcv8+ s

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-09-04 Thread Robert Haas
On Tue, Aug 5, 2014 at 11:55 AM, Robert Haas wrote: > On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote: >>> > If you want to do that, it's fine with me. What I would do is: >>> > >>> > - Back-patch the addition of the sparcv8+ stuff all the way. If >>> > anyone's running anything older, let

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-08-05 Thread Robert Haas
On Sun, Jul 6, 2014 at 3:12 PM, Andres Freund wrote: >> > If you want to do that, it's fine with me. What I would do is: >> > >> > - Back-patch the addition of the sparcv8+ stuff all the way. If >> > anyone's running anything older, let them complain... >> > - Remove the special case for MIPS wi

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-06 Thread Andres Freund
On 2014-07-06 15:02:21 -0400, Robert Haas wrote: > On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote: > >>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give > >>> up on SPARC completely, but maybe we should only add the cases for > >>> sparcv8+ and above? That at least has

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-06 Thread Robert Haas
On Tue, Jul 1, 2014 at 12:22 PM, Robert Haas wrote: >>> Since we have a Sun Studio machine in the buildfarm, we shouldn't give >>> up on SPARC completely, but maybe we should only add the cases for >>> sparcv8+ and above? That at least has some chance of getting tested. >> >> That we have code fo

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-02 Thread Robert Haas
On Wed, Jul 2, 2014 at 4:06 AM, Mark Cave-Ayland wrote: > The point I wanted to make was that there are certain applications for which > SPARCv8 is still certified for particular military/aerospace use. While I > don't use it myself, some people are still using it enough to want to > contribute QE

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-02 Thread Mark Cave-Ayland
On 02/07/14 08:36, Andres Freund wrote: On 2014-07-01 20:21:37 -0400, Tom Lane wrote: Andres Freund writes: On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: Also if you're struggling for Sun buildfarm animals, recent versions of QEMU will quite happily install and run later versions of

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-02 Thread Andres Freund
On 2014-07-01 20:21:37 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: > >> Also if you're struggling for Sun buildfarm animals, recent versions of > >> QEMU > >> will quite happily install and run later versions of 32-bit Solaris over > >>

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Tom Lane
Andres Freund writes: > On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: >> Also if you're struggling for Sun buildfarm animals, recent versions of QEMU >> will quite happily install and run later versions of 32-bit Solaris over >> serial, and 2.0 even manages to give you a cgthree framebuffe

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Andres Freund
On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote: > On 01/07/14 11:04, Andres Freund wrote: > > >>Since we have a Sun Studio machine in the buildfarm, we shouldn't give > >>up on SPARC completely, but maybe we should only add the cases for > >>sparcv8+ and above? That at least has some chance

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Mark Cave-Ayland
On 01/07/14 11:04, Andres Freund wrote: Since we have a Sun Studio machine in the buildfarm, we shouldn't give up on SPARC completely, but maybe we should only add the cases for sparcv8+ and above? That at least has some chance of getting tested. That we have code for sparcv7 is ridiculous bt

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Robert Haas
On Tue, Jul 1, 2014 at 4:54 PM, Tom Lane wrote: > Robert Haas writes: >> Despite my concerns about keeping the list of supported atomics short, >> and I do have concerns in that area, I'm not really sure that we have >> much choice but to go in that direction. We can't accept a >5x >> performanc

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Tom Lane
Robert Haas writes: > Despite my concerns about keeping the list of supported atomics short, > and I do have concerns in that area, I'm not really sure that we have > much choice but to go in that direction. We can't accept a >5x > performance hit in the name of portability, and that's literally

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Robert Haas
On Tue, Jul 1, 2014 at 2:52 PM, Tom Lane wrote: > Robert Haas writes: >> The bottom line is that I love supporting obscure platforms as much as >> anyone here, and several other committers are already telling me that >> I love it too much. We've got to draw the line somewhere, and I think >> ref

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Tom Lane
Robert Haas writes: > The bottom line is that I love supporting obscure platforms as much as > anyone here, and several other committers are already telling me that > I love it too much. We've got to draw the line somewhere, and I think > refusing to ship newly-written code that we have exactly z

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Robert Haas
On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure wrote: > A few years back I ported the postresql client libraries and a few > other pieces of software (in particular subversion) to a lot of > obscure platforms (old sparc, hpux, irix, older aix, etc etc). > Getting a modern gcc working on those pla

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Andres Freund
On 2014-07-01 11:46:19 -0500, Merlin Moncure wrote: > On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote: > > On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund > > wrote: > >>> You know, looking at this, I wonder if we shouldn't just remove > >>> support for ARMv5 instead of making a blind stab at a

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Merlin Moncure
On Tue, Jul 1, 2014 at 11:22 AM, Robert Haas wrote: > On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote: >>> You know, looking at this, I wonder if we shouldn't just remove >>> support for ARMv5 instead of making a blind stab at a fix. >> >> Well, I argued that way for a while ;). We don't even

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Robert Haas
On Tue, Jul 1, 2014 at 6:04 AM, Andres Freund wrote: >> You know, looking at this, I wonder if we shouldn't just remove >> support for ARMv5 instead of making a blind stab at a fix. > > Well, I argued that way for a while ;). We don't even need to really > desupport it, but just say it's not suppo

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-07-01 Thread Andres Freund
On 2014-06-30 22:44:58 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote: > > On 2014-06-30 19:22:59 +0200, Andres Freund wrote: > >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >> >, which if I understand you correctly are ARM without GCC > >> > atomics, Spar

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Robert Haas
On Mon, Jun 30, 2014 at 6:28 PM, Andres Freund wrote: > On 2014-06-30 19:22:59 +0200, Andres Freund wrote: >> On 2014-06-30 12:46:29 -0400, Robert Haas wrote: >> >, which if I understand you correctly are ARM without GCC >> > atomics, Sparc, and MIPS. >> >> I've to revise my statement on MIPS, it

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Andres Freund
On 2014-06-30 19:22:59 +0200, Andres Freund wrote: > On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >, which if I understand you correctly are ARM without GCC > > atomics, Sparc, and MIPS. > > I've to revise my statement on MIPS, it actually looks safe. I seem to > have missed that it has its

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Andres Freund
On 2014-06-30 12:46:29 -0400, Robert Haas wrote: > >> But trying to use a spinlock > >> acquire-release to shore up problems with the spinlock release > >> implementation makes my head explode. > > > > Well, it actually makes some sense. Nearly any TAS() implementation is > > going to have some mem

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Robert Haas
On Mon, Jun 30, 2014 at 12:20 PM, Andres Freund wrote: > On 2014-06-30 11:38:31 -0400, Robert Haas wrote: >> On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund >> wrote: >> >> Now, we want to make these >> >> operations compiler fences as well, and AIUI your proposal for that is >> >> to make NEW_S

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Andres Freund
On 2014-06-30 11:38:31 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund > wrote: > >> Now, we want to make these > >> operations compiler fences as well, and AIUI your proposal for that is > >> to make NEW_S_UNLOCK(lock) = out of line function call + S_LOCK(dummy) > >>

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Robert Haas
On Mon, Jun 30, 2014 at 11:17 AM, Andres Freund wrote: >> > Solaris seems to run with TSO enabled for SPARC (whereas linux uses RMO, >> > relaxed memory ordering), so it's probably fine to just use the compiler >> > barrier. >> >> If it isn't, that's a change that has nothing to do with making >>

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Andres Freund
On 2014-06-30 10:05:44 -0400, Robert Haas wrote: > On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote: > > I think it continues in the tradition of making s_lock.h ever harder to > > follow. But it's still better than what we have now from a correctness > > perspective. > > Well, as you and I h

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Robert Haas
On Mon, Jun 30, 2014 at 9:26 AM, Andres Freund wrote: > I think it continues in the tradition of making s_lock.h ever harder to > follow. But it's still better than what we have now from a correctness > perspective. Well, as you and I have discussed before, someday we probably need to get rid of

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Andres Freund
Hi, On 2014-06-30 08:03:40 -0400, Robert Haas wrote: > On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote: > >> No, I think it's going to be *much* simpler than that. How about I > >> take a crack at this next week and then either (a) I'll see why it's a > >> bad idea and we can go from there

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-30 Thread Robert Haas
On Sat, Jun 28, 2014 at 9:41 AM, Andres Freund wrote: >> No, I think it's going to be *much* simpler than that. How about I >> take a crack at this next week and then either (a) I'll see why it's a >> bad idea and we can go from there or (b) you can review what I come up >> with and tell me why i

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-28 Thread Andres Freund
On 2014-06-28 15:41:46 +0200, Andres Freund wrote: > On 2014-06-28 09:25:32 -0400, Robert Haas wrote: > > No, I think it's going to be *much* simpler than that. How about I > > take a crack at this next week and then either (a) I'll see why it's a > > bad idea and we can go from there or (b) you c

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-28 Thread Andres Freund
On 2014-06-28 09:25:32 -0400, Robert Haas wrote: > On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund wrote: > >> > Do we want to introduce acquire/release barriers? Or do we want to > >> > redefine the current barriers to be strong enough for that? > >> > >> Well, unless we're prepared to dump suppor

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-28 Thread Robert Haas
On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund wrote: >> > Do we want to introduce acquire/release barriers? Or do we want to >> > redefine the current barriers to be strong enough for that? >> >> Well, unless we're prepared to dump support for an awful lot of >> platfomrs, trying to support acqui

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-28 Thread Andres Freund
On 2014-06-27 22:34:19 -0400, Robert Haas wrote: > On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund wrote: > > On 2014-06-27 13:04:02 -0400, Robert Haas wrote: > >> On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote: > >> > Andres Freund writes: > >> >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote: >

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-27 Thread Robert Haas
On Fri, Jun 27, 2014 at 2:04 PM, Andres Freund wrote: > On 2014-06-27 13:04:02 -0400, Robert Haas wrote: >> On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote: >> > Andres Freund writes: >> >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote: >> >>> Surely it had better be a read barrier as well? >> >

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-27 Thread Andres Freund
On 2014-06-27 13:04:02 -0400, Robert Haas wrote: > On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote: > > Andres Freund writes: > >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > >>> Surely it had better be a read barrier as well? > > > >> I don't immediately see why it has to be read barrier? Ho

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-27 Thread Andres Freund
On 2014-06-27 13:00:34 -0400, Robert Haas wrote: > There are two separate issues here: > > 1. SpinLockAcquire and SpinLockRelease are not guaranteed to be > compiler barriers, so all relevant memory accesses in the critical > section need to be done using volatile pointers. Failing to do this > i

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-27 Thread Robert Haas
On Thu, Jun 26, 2014 at 6:40 PM, Tom Lane wrote: > Andres Freund writes: >> On 2014-06-26 14:13:07 -0700, Tom Lane wrote: >>> Surely it had better be a read barrier as well? > >> I don't immediately see why it has to be read barrier? Hoisting a load >> from after the release into the locked area

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-27 Thread Robert Haas
On Thu, Jun 26, 2014 at 5:01 PM, Andres Freund wrote: > But a) isn't really avoidable because it'll otherwise generate compiler > warnings and b) is done that way all over the tree. E.g. lwlock.c has > several copies of (note the nonvolatility of proc): > volatile LWLock *lock = l; >

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Andres Freund
On 2014-06-26 15:40:11 -0700, Tom Lane wrote: > Andres Freund writes: > > On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > >> Surely it had better be a read barrier as well? > > > I don't immediately see why it has to be read barrier? Hoisting a load > > from after the release into the locked area

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Andres Freund
Hi, On 2014-06-26 23:01:10 +0200, Andres Freund wrote: > I think we should rework things so that we fall back to > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > we have right now. > That'd require to make barrier.h independent from s_lock.h, but I think > that'd be a p

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Tom Lane
Andres Freund writes: > On 2014-06-26 14:13:07 -0700, Tom Lane wrote: >> Surely it had better be a read barrier as well? > I don't immediately see why it has to be read barrier? Hoisting a load > from after the release into the locked area of code should be safe? No doubt, but delaying a read ti

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Andres Freund
On 2014-06-26 14:13:07 -0700, Tom Lane wrote: > Andres Freund writes: > > I think we should rework things so that we fall back to > > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > > we have right now. > > Surely it had better be a read barrier as well? I don't immedi

Re: [HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Tom Lane
Andres Freund writes: > I think we should rework things so that we fall back to > pg_write_barrier(), (*((volatile slock_t *) (lock)) = 0) instead of what > we have right now. Surely it had better be a read barrier as well? And S_LOCK the same? regards, tom lane -- Se

[HACKERS] Spinlocks and compiler/memory barriers

2014-06-26 Thread Andres Freund
Hi, I just spent 20+ hours debugging a elusive problem which only happened under heavy concurrency. Slight changes to the code made it disappear. In the end it turned out that gcc liked to move *one* instruction across the SpinLockRelease() - and only sometimes. Unrelated changes made the vanish.