On Tue, Jun 16, 2020 at 08:35:58PM -0700, Andres Freund wrote:
> On June 16, 2020 8:24:29 PM PDT, Noah Misch wrote:
> >Suppose the initializing process does:
> >
> > pg_atomic_init_u64(&somestruct->atomic, 123);
> > somestruct->atomic_ready = true;
> >
> >In released versions, any process observ
Andres Freund writes:
> On June 16, 2020 8:24:29 PM PDT, Noah Misch wrote:
>> Suppose the initializing process does:
>>
>> pg_atomic_init_u64(&somestruct->atomic, 123);
>> somestruct->atomic_ready = true;
>>
>> In released versions, any process observing atomic_ready==true will
>> observe
>> th
Hi,
On June 16, 2020 8:24:29 PM PDT, Noah Misch wrote:
>On Sun, Jun 14, 2020 at 09:16:20PM -0700, Andres Freund wrote:
>> On 2020-06-14 18:55:27 -0700, Noah Misch wrote:
>> > Does something guarantee the write will be globally-visible by the
>time the
>> > first concurrent accessor shows up?
>>
On Sun, Jun 14, 2020 at 09:16:20PM -0700, Andres Freund wrote:
> On 2020-06-14 18:55:27 -0700, Noah Misch wrote:
> > Does something guarantee the write will be globally-visible by the time the
> > first concurrent accessor shows up?
>
> The function comments say:
>
> *
> * Has to be done before
Andres Freund writes:
> On 2020-06-14 22:30:25 -0400, Tom Lane wrote:
>> Perhaps it'd be worth putting a memory barrier at the end of the _init
>> function(s)? As you say, this is hypothetical right now, but that'd be
>> a cheap improvement.
> I don't think it'd be that cheap for some cases. The
Hi,
On 2020-06-14 22:30:25 -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jun 07, 2020 at 12:23:35AM -0400, Tom Lane wrote:
> >> ... 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 sim
Hi,
On 2020-06-14 18:55:27 -0700, Noah Misch wrote:
> Does something guarantee the write will be globally-visible by the time the
> first concurrent accessor shows up?
The function comments say:
*
* Has to be done before any concurrent usage..
*
* No barrier semantics.
> (If not, one could
Noah Misch writes:
> On Sun, Jun 07, 2020 at 12:23:35AM -0400, Tom Lane wrote:
>> ... 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?
On Sun, Jun 07, 2020 at 12:23:35AM -0400, Tom Lane wrote:
> I experimented with running "make check" on ARM64 under a reasonably
> bleeding-edge valgrind (3.16.0). One thing I ran into is that
> regress.c's test_atomic_ops fails; valgrind shows the stack trace
>
>fun:__aarch64_cas8_acq_rel
>
Andres Freund writes:
> And done.
LGTM, thanks!
regards, tom lane
Hi,
On 2020-06-08 18:21:06 -0400, Tom Lane wrote:
> > 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 som
Andres Freund 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. W
Hi,
On 2020-06-07 00:23:35 -0400, Tom Lane wrote:
> I experimented with running "make check" on ARM64 under a reasonably
> bleeding-edge valgrind (3.16.0). One thing I ran into is that
> regress.c's test_atomic_ops fails; valgrind shows the stack trace
>
>fun:__aarch64_cas8_acq_rel
>fun:
13 matches
Mail list logo
