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:
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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-04-17 22:52:26|
|Subject: Re: testing HS/SR - 1 vs 2 performance |
|Previous:||From: Simon Riggs||Date: 2010-04-17 22:41:35|
|Subject: Re: master in standby mode croaks|