| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: anole: assorted stability problems |
| Date: | 2015-06-29 10:11:08 |
| Message-ID: | 20150629101108.GB17640@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> #define S_UNLOCK(lock) \
> do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
barrier? Shouldn't this be a _Asm_mf()?
> which immediately raises the question of why omitting the "volatile"
> cast is okay.
Should be fine if _Asm_sched_fence() were a proper memory (or een
release) barrier. Which I don't think it is.
> I also wonder if we don't need a second _Asm_sched_fence() after the
> lock release.
Shouldn't be needed - the only thing that could be reordered is the
actual lock release. Which will just impact timing in a minor manner (it
can't move into another locked section).
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2015-06-29 11:54:40 | Re: Rework the way multixact truncations work |
| Previous Message | Amit Langote | 2015-06-29 09:36:23 | Re: UPSERT on partition |