| От | Tom Lane |
|---|---|
| Тема | Re: Reducing overhead of frequent table locks |
| Дата | |
| Msg-id | 3368.1306530111@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Reducing overhead of frequent table locks (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> When a strong lock is taken or released, we have to increment or
> decrement strong_lock_counts[fasthashpartition]. Here's the question:
> is that atomic? In other words, suppose that strong_lock_counts[42]
> starts out at 0, and two backends both do ++strong_lock_counts[42].
> Are we guaranteed to end up with "2" in that memory location or might
> we unluckily end up with "1"? I think the latter is possible... and
> some guard is needed to make sure that doesn't happen.
There are "atomic increment" primitives on most/all multiprocessors,
although availing ourselves of them everywhere will take an amount of
work not unlike developing the spinlock primitives :-(. You are dead
right that this is unsafe without that.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера