Re: Latches vs lwlock contention

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: Latches vs lwlock contention
Дата
Msg-id CAJ7c6TMxPGevTBLvZHCmwEpcMkVG=gUQq_7g6+77Nn9gJQQmjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Latches vs lwlock contention  (Peter Eisentraut <peter@eisentraut.org>)
Список pgsql-hackers
Hi,

> Maybe this is all ok, but it would be good to make the assumptions more
> explicit.

Here are my two cents.

```
static void
SetLatchV(Latch **latches, int nlatches)
{
    /* Flush any other changes out to main memory just once. */
    pg_memory_barrier();

    /* Keep only latches that are not already set, and set them. */
    for (int i = 0; i < nlatches; ++i)
    {
        Latch       *latch = latches[i];

        if (!latch->is_set)
            latch->is_set = true;
        else
            latches[i] = NULL;
    }

    pg_memory_barrier();

[...]

void
SetLatches(LatchGroup *group)
{
    if (group->size > 0)
    {
        SetLatchV(group->latches, group->size);

[...]
```

I suspect this API may be error-prone without some additional
comments. The caller (which may be an extension author too) may rely
on the implementation details of SetLatches() / SetLatchV() and use
the returned group->latches[] values e.g. to figure out whether he
attempted to change the state of the given latch. Even worse, one can
mistakenly assume that the result says exactly if the caller was the
one who changed the state of the latch. This being said I see why this
particular implementation was chosen.

I added corresponding comments to SetLatchV() and SetLatches(). Also
the patchset needed a rebase. PFA v4.

It passes `make installcheck-world` on 3 machines of mine: MacOS x64,
Linux x64 and Linux RISC-V.


--
Best regards,
Aleksander Alekseev

Вложения

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

Предыдущее
От: Isaac Morland
Дата:
Сообщение: Re: Forgive trailing semicolons inside of config files
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Forgive trailing semicolons inside of config files