Re: better atomics

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: better atomics
Дата
Msg-id 10634.1382992175@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: better atomics  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: better atomics  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-10-28 16:06:47 -0400, Tom Lane wrote:
>> You're both just handwaving.  How many is "many", and which ones might
>> we actually have enough use for to justify dealing with such a dependency?
>> I don't think we should buy into this without some pretty concrete
>> justification.

> Well, I don't think either of us is suggesting to make it required. But
> it's going to be painful to go through the list of compilers repeatedly
> instead of just adding all operations at one. I am willing to do that
> for several compilers once, but I don't want to do it in each and every
> feature submission using another atomic op.

Basically I'm arguing that that choice is backwards.  We should decide
first what the list of supported atomics is going to be, and each and
every element of that list has to have a convincing concrete argument
why we need to support it.  Not "we might want this someday".  Because
when someday comes, that's when we'd be paying the price of finding out
which platforms actually support the primitive correctly and with what
performance.  Or if someday never comes, we're not ahead either.

Or if you like: no matter what you do, the first feature submission
that makes use of a given atomic op is going to suffer pain.  I don't
want to still be suffering that pain two or three years out.  The shorter
the list of allowed atomic ops, the sooner we'll be done with debugging
them.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: better atomics
Следующее
От: Andres Freund
Дата:
Сообщение: Re: OSX doesn't accept identical source/target for strcpy() anymore