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 по дате отправления: