Re: testing HS/SR - 1 vs 2 performance
От | Simon Riggs |
---|---|
Тема | Re: testing HS/SR - 1 vs 2 performance |
Дата | |
Msg-id | 1271544366.8305.12491.camel@ebony обсуждение исходный текст |
Ответ на | Re: testing HS/SR - 1 vs 2 performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: testing HS/SR - 1 vs 2 performance
Re: testing HS/SR - 1 vs 2 performance |
Список | pgsql-hackers |
On Sat, 2010-04-17 at 16:48 -0400, Tom Lane wrote: > > We search the array between tail and head. If the head moves by integer > > overwrite just as already happens for xid assignment, then we would use > > the new head for the search. The code is careful to fetch only once. > > ... but this will not. You need to use a lock, because there is > otherwise no guarantee that other processors see the write into the > array element before they see the change in the head pointer. > > > I would freely admit I know absolutely nothing about details of > > weak-memory-ordering machines and have not considered them at all. How > > would what I have proposed fail to work, yet what we already rely on > > work correctly? Do the circumstances differ? > > Yes. We have memory ordering instructions inserted in the lock > acquisition/release code. Trying to access and modify a shared-memory > data structure without any locking will not work. > > There are some places where we suppose that a *single* write into shared > memory can safely be done without a lock, if we're not too concerned > about how soon other transactions will see the effects. But what you > are proposing here requires more than one related write. > > I've been burnt by this myself: > http://archives.postgresql.org/pgsql-committers/2008-06/msg00228.php W O W - thank you for sharing. What I'm not clear on is why you've used a spinlock everywhere when only weak-memory thang CPUs are a problem. Why not have a weak-memory-protect macro that does does nada when the hardware already protects us? (i.e. a spinlock only for the hardware that needs it). -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: