On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Solving the problem for linux only, or gcc only, isn't going to get us > to a place where we can stop volatile-izing call sites. We need to be > sure it works for every single case supported by s_lock.h.
Yep, that's the problem all right. > I think you may be right that using __asm__ __volatile__ in gcc > S_UNLOCK cases would be a big step forward, but it needs more research > to see if that's the only fix needed. I agree, but I will note that I have done a fair bit of research on this already, and there are definitions in storage/barrier.h for pg_compiler_barrier() that cover gcc, icc, HP's aCC, MSVC, and Borland C. There are probably other wacky compilers out there, though: looking at the build farm, I see Sun Studio and sco cc as cases that would likely need some attention. Are there any compilers not represented in the build-farm that we'd mind breaking? If we can get working pg_compiler_barrier() definitions for all the compilers we care about, the rest is probably mostly a question of going through s_lock.h and inserting compiler barriers anywhere that they aren't already implied by the existing code. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
