Re: Latches with weak memory ordering (Re: max_wal_senders must die)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Дата
Msg-id 15085.1289837520@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> In SetLatch, is it enough to add the SpinLockAcquire() call *after* 
> checking that is_set is not already set? Ie. still do the quick exit 
> without holding a lock. Or do we need a memory barrier operation before 
> the fetch, to ensure that we see if the other process has just cleared 
> the flag with ResetLatch() ? Presumable ResetLatch() needs to call 
> SpinLockAcquire() anyway to ensure that other processes see the clearing 
> of the flag.

Hmm ... I just remembered the reason why we didn't use a spinlock in
these functions already.  Namely, that it's unsafe for a signal handler
to try to acquire a spinlock that the interrupted code might be holding.
So I think a bit more thought is needed here.  Maybe we need to bite the
bullet and do memory barriers ...
        regards, tom lane


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Extensions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons