Robert Haas writes:
> The only point I'm making here is that the width of a spinlock is not
> irrelevant.
Sure, but it does not follow that we need to get all hot and bothered
about the width of pg_atomic_flag, which has yet to find its first
use-case. When and if its width becomes a demonstrabl
On Tue, Jan 3, 2017 at 12:07 PM, Tom Lane wrote:
> [ shrug... ] I have not seen you putting any effort into optimizing
> slock_t on non-x86 architectures, where it might make a difference today.
> Why all the concern about shaving hypothetical future bytes for
> pg_atomic_flag?
I don't know what
Robert Haas writes:
> On Tue, Jan 3, 2017 at 11:11 AM, Tom Lane wrote:
A survey of s_lock.h shows that we prefer char-width slock_t only on
these architectures:
x86
sparc (but not sparcv9, there we use int)
m68k
vax
>>> I don't think that's right, because on m
On Tue, Jan 3, 2017 at 11:11 AM, Tom Lane wrote:
>>> A survey of s_lock.h shows that we prefer char-width slock_t only on
>>> these architectures:
>>>
>>> x86
>>> sparc (but not sparcv9, there we use int)
>>> m68k
>>> vax
>
>> I don't think that's right, because on my MacBook Pro:
>
> ... which is
Robert Haas writes:
> On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane wrote:
>> After further study, I'm inclined to just propose that we flip the default
>> width of pg_atomic_flag in generic-gcc.h: use int not char if both are
>> available. The only modern platform where that's the wrong thing is x86
On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane wrote:
> I wrote:
>> But that doesn't really detract from my point, which is that it's
>> totally silly for us to imagine that char and word-wide atomic ops are
>> interchangeable on all platforms and we can flip a coin to decide which
>> to use as long as
I wrote:
> But that doesn't really detract from my point, which is that it's
> totally silly for us to imagine that char and word-wide atomic ops are
> interchangeable on all platforms and we can flip a coin to decide which
> to use as long as the configure probes don't fail outright. Even given
>
Andres Freund writes:
> On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane
> wrote:
>> and got no warnings and the attached output. I'm not very good at
>> reading PPC assembler, but I think what is happening in the "char" case is
>> that
>> gcc is trying to emulate a byte-wide operation usin
On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote:
>and got no warnings and the attached output. I'm not very good at
>reading
>PPC assembler, but I think what is happening in the "char" case is that
>gcc is trying to emulate a byte-wide operation using a word-wide one,
>ie an lwarx/stw
On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote:
>Andres Freund writes:
>> On 2016-12-30 00:44:33 -0500, Tom Lane wrote:
>>> Perhaps it could be argued that there's a FreeBSD compiler bug here,
>>> but what I'm wondering is why configure believes that this:
>>>
>>> [char lock = 0;
>>
Andres Freund writes:
> On 2016-12-30 00:44:33 -0500, Tom Lane wrote:
>> Perhaps it could be argued that there's a FreeBSD compiler bug here,
>> but what I'm wondering is why configure believes that this:
>>
>> [char lock = 0;
>> __sync_lock_test_and_set(&lock, 1);
>> __sync_lock_release(&lock);]
Hi,
On 2016-12-30 00:44:33 -0500, Tom Lane wrote:
> *** /usr/home/tgl/pgsql/src/test/regress/expected/lock.out Thu Dec 29
> 19:37:50 2016
> --- /usr/home/tgl/pgsql/src/test/regress/results/lock.out Fri Dec 30
> 00:31:01 2016
> ***
> *** 63,70
> -- atomic ops tests
>
12 matches
Mail list logo
