Re: valgrind versus pg_atomic_init()
От | Tom Lane |
---|---|
Тема | Re: valgrind versus pg_atomic_init() |
Дата | |
Msg-id | 2110776.1591654866@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: valgrind versus pg_atomic_init() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: valgrind versus pg_atomic_init()
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2020-06-07 00:23:35 -0400, Tom Lane wrote: >> so my first thought was that we just needed an architecture-specific >> variant of that. But on thinking more about this, it seems like >> generic.h's version of pg_atomic_init_u64_impl is just fundamentally >> misguided. Why isn't it simply assigning the value with an ordinary >> unlocked write? By definition, we had better not be using this function >> in any circumstance where there might be conflicting accesses, so I don't >> see why we should need to tolerate a valgrind exception here. Moreover, >> if a simple assignment *isn't* good enough, then surely the spinlock >> version in atomics.c is 100% broken. > Yea, it could just do that. It seemed slightly easier/clearer, back when > I wrote it, to just use pg_atomic_write* for the initialization, but > this seems enough of a reason to stop doing so. Will change it in all > branches, unless somebody sees a reason to not do so? Works for me. regards, tom lane
В списке pgsql-hackers по дате отправления: