On Mon, Nov 22, 2010 at 6:54 AM, Heikki Linnakangas
wrote:
> On 21.11.2010 15:18, Robert Haas wrote:
>>
>> On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote:
>>>
>>> Robert Haas writes:
So what DO we need to guard against here?
>>>
>>> I think the general problem can be stated as "proces
On 21.11.2010 15:18, Robert Haas wrote:
On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote:
Robert Haas writes:
So what DO we need to guard against here?
I think the general problem can be stated as "process A changes two or
more values in shared memory in a fairly short span of time, and proc
On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> So what DO we need to guard against here?
>
> I think the general problem can be stated as "process A changes two or
> more values in shared memory in a fairly short span of time, and process
> B, which is concurrently exam
Robert Haas writes:
> So what DO we need to guard against here?
I think the general problem can be stated as "process A changes two or
more values in shared memory in a fairly short span of time, and process
B, which is concurrently examining the same variables, sees those
changes occur in a diff
On Fri, Nov 19, 2010 at 5:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> But what about timings vs. random other stuff? Like in this case
>> there's a problem if the signal arrives before the memory update to
>> latch->is_set becomes visible. I don't know what we need to do to
>> guarantee tha
On Saturday 20 November 2010 00:08:07 Tom Lane wrote:
> Andres Freund writes:
> > On Friday 19 November 2010 18:46:00 Tom Lane wrote:
> >> I poked around in the Intel manuals a bit. They do have mfence (also
> >> lfence and sfence) but so far as I can tell, those are only used to
> >> manage load
Andres Freund writes:
> On Friday 19 November 2010 18:46:00 Tom Lane wrote:
>> I poked around in the Intel manuals a bit. They do have mfence (also
>> lfence and sfence) but so far as I can tell, those are only used to
>> manage loads and stores that are issued by special instructions that
>> exp
Robert Haas writes:
> But what about timings vs. random other stuff? Like in this case
> there's a problem if the signal arrives before the memory update to
> latch->is_set becomes visible. I don't know what we need to do to
> guarantee that.
I don't believe there's an issue there. A context s
On Fri, Nov 19, 2010 at 1:51 PM, Tom Lane wrote:
> However, for lock-free interactions I think this model isn't terribly
> helpful: it's not clear what is "inside" and what is "outside" the sync
> block, and forcing your code into that model doesn't improve either
> clarity or performance. What y
On Friday 19 November 2010 20:03:27 Andres Freund wrote:
> Which means something like (in intel's terminology) can happen:
>
> initially x = 0
>
> P1: mov [_X], 1
> P1: lock xchg Y, 1
>
> P2. lock xchg [_Z], 1
> P2: mov r1, [_X]
>
> A valid result is that r1 on P2 is 0.
>
> I think that is not
On Friday 19 November 2010 18:46:00 Tom Lane wrote:
> I wrote:
> > Markus Wanner writes:
> >> Well, that certainly doesn't apply to full fences, that are not specific
> >> to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
> >> 'mf' on ia64.
> >
> > Hm, what do those do exactl
Tom Lane wrote:
> What you typically need is a guarantee about the order in which
> writes become visible.
> In some cases you also need to guarantee the order of reads.
Doesn't that suggest different primitives?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
"Kevin Grittner" writes:
> Tom Lane wrote:
>> That's really entirely the wrong way to think about it. You need
>> a fence primitive, full stop. It's a sequence point, not an
>> operation in itself.
> I was taking it to mean something similar to the memory guarantees
> around synchronized block
Tom Lane wrote:
> Robert Haas writes:
>> I think it would be useful to try to build up a library of
>> primitives in this area. For this particular task, we really
>> only need a write-with-fence primitive and a read-with-fence
>> primitive.
>
> That's really entirely the wrong way to think abo
I wrote:
> Markus Wanner writes:
>> Well, that certainly doesn't apply to full fences, that are not specific
>> to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
>> 'mf' on ia64.
> Hm, what do those do exactly?
I poked around in the Intel manuals a bit. They do have mfence
* Andres Freund:
> I was never talking about 'locking the whole cache' - I was talking about
> flushing/fencing it like a "global" read/write barrier would. And "lock
> xchgb/xaddl" does not imply anything for other cachelines but its own.
My understanding is that once you've seen the result of
Robert Haas writes:
> I think it would be useful to try to build up a library of primitives
> in this area. For this particular task, we really only need a
> write-with-fence primitive and a read-with-fence primitive.
That's really entirely the wrong way to think about it. You need a
fence prim
On Fri, Nov 19, 2010 at 10:44 AM, Tom Lane wrote:
> Robert Haas writes:
>> I completely agree, but I'm not too sure I want to drop support for
>> any platform for which we haven't yet implemented such primitives.
>> What's different about this case is that "fall back to taking the spin
>> lock" i
Andres Freund writes:
> I was never talking about 'locking the whole cache' - I was talking about
> flushing/fencing it like a "global" read/write barrier would. And "lock
> xchgb/xaddl" does not imply anything for other cachelines but its own.
If that's the case, why aren't the parallel regres
On Friday 19 November 2010 17:25:57 Tom Lane wrote:
> Andres Freund writes:
> > Locked statments like 'lock xaddl;' guarantee that the specific operands
> > (or their cachelines) are visible on all processors and are done
> > atomically - but its not influencing the whole cache like mfence would.
Andres Freund writes:
> Locked statments like 'lock xaddl;' guarantee that the specific operands (or
> their cachelines) are visible on all processors and are done atomically - but
> its not influencing the whole cache like mfence would.
Where is this "locking the whole cache" meme coming from?
On Friday 19 November 2010 16:51:00 Tom Lane wrote:
> Markus Wanner writes:
> > Well, that certainly doesn't apply to full fences, that are not specific
> > to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
> > 'mf' on ia64.
> Hm, what do those do exactly? We've never had any
On 11/19/2010 04:51 PM, Tom Lane wrote:
> Hm, what do those do exactly?
"Performs a serializing operation on all load-from-memory and
store-to-memory instructions that were issued prior the MFENCE
instruction." [1]
Given the memory ordering guarantees of x86, this instruction might only
be releva
Markus Wanner writes:
> Well, that certainly doesn't apply to full fences, that are not specific
> to a particular piece of memory. I'm thinking of 'mfence' on x86_64 or
> 'mf' on ia64.
Hm, what do those do exactly? We've never had any such thing in the
Intel-ish spinlock asm, but if out-of-orde
Robert Haas writes:
> I completely agree, but I'm not too sure I want to drop support for
> any platform for which we haven't yet implemented such primitives.
> What's different about this case is that "fall back to taking the spin
> lock" is not a workable option.
The point I was trying to make
Robert Haas writes:
> ... The reason memory
> barriers solve the problem is because they'll be atomically released
> when we jump into the signal handler, but that is not true of a
> spin-lock or a semaphore.
Hm, I wonder whether your concern is stemming from a wrong mental
model. There is nothi
On 11/19/2010 03:58 PM, Aidan Van Dyk wrote:
> Well, it's not quite enough just to call into the kernel to serialize
> on "some point of memory", because your point is to make sure that
> *this particular piece of memory* is coherent.
Well, that certainly doesn't apply to full fences, that are not
On Friday 19 November 2010 15:58:39 Aidan Van Dyk wrote:
> On Fri, Nov 19, 2010 at 9:49 AM, Andres Freund wrote:
> > Well, its not generally true - you are right there. But there is a wide
> > range for syscalls available where its inherently true (which is what I
> > sloppily referred to). And yo
On Fri, Nov 19, 2010 at 9:31 AM, Robert Haas wrote:
>> Just a small point of clarification - you need to have both that
>> unknown archtecture, and that architecture has to have postgres
>> process running simultaneously on difference CPUs with different
>> caches that are incoherent to have thos
On Fri, Nov 19, 2010 at 10:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> If we're going to work on memory primitives, I would much rather see
>> us put that effort into, say, implementing more efficient LWLock
>> algorithms to solve the bottlenecks that the MOSBENCH guys found,
>> rather than s
Robert Haas writes:
> If we're going to work on memory primitives, I would much rather see
> us put that effort into, say, implementing more efficient LWLock
> algorithms to solve the bottlenecks that the MOSBENCH guys found,
> rather than spending it on trying to avoid a minor API complication
>
On Fri, Nov 19, 2010 at 9:49 AM, Andres Freund wrote:
> Well, its not generally true - you are right there. But there is a wide range
> for syscalls available where its inherently true (which is what I sloppily
> referred to). And you are allowed to call a, although quite restricted, set of
> syst
On Fri, Nov 19, 2010 at 9:51 AM, Andres Freund wrote:
> On Friday 19 November 2010 15:49:45 Robert Haas wrote:
>> If we're going to work on memory primitives, I would much rather see
>> us put that effort into, say, implementing more efficient LWLock
>> algorithms to solve the bottlenecks that the
On Friday 19 November 2010 15:49:45 Robert Haas wrote:
> If we're going to work on memory primitives, I would much rather see
> us put that effort into, say, implementing more efficient LWLock
> algorithms to solve the bottlenecks that the MOSBENCH guys found,
> rather than spending it on trying to
On Friday 19 November 2010 15:14:58 Robert Haas wrote:
> On Thu, Nov 18, 2010 at 11:38 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I'm all in favor of having some memory ordering primitives so that we
> >> can try to implement better algorithms, but if we use it here it
> >> amounts to a fai
On Friday 19 November 2010 15:38:37 Robert Haas wrote:
> Eh, really? If there's a workaround for platforms for which we don't
> know what the appropriate read-fencing incantation is, then I'd feel
> more comfortable about doing this. But I don't see how to make that
> work. The whole problem her
On Fri, Nov 19, 2010 at 9:35 AM, Aidan Van Dyk wrote:
> On Fri, Nov 19, 2010 at 9:31 AM, Robert Haas wrote:
>>> Just a small point of clarification - you need to have both that
>>> unknown archtecture, and that architecture has to have postgres
>>> process running simultaneously on difference CPU
On Fri, Nov 19, 2010 at 9:29 AM, Andres Freund wrote:
> On Friday 19 November 2010 15:16:24 Robert Haas wrote:
>> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund wrote:
>> > So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
>> > spinlocks for that purpose - no idea where th
On Friday 19 November 2010 15:29:10 Andres Freund wrote:
> Besides, we can just jump into the kernel and back in that case (which the
> TAS implementation already does), that does more than just a fence...
Or if you don't believe that is enough initialize a lock on the stack, lock
and forget it..
On Fri, Nov 19, 2010 at 9:16 AM, Robert Haas wrote:
> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund wrote:
>> So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
>> spinlocks for that purpose - no idea where that is true these days.
>
> Me neither, which is exactly the prob
On Fri, Nov 19, 2010 at 9:27 AM, Aidan Van Dyk wrote:
> On Fri, Nov 19, 2010 at 9:16 AM, Robert Haas wrote:
>> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund wrote:
>>> So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
>>> spinlocks for that purpose - no idea where that i
On Friday 19 November 2010 15:16:24 Robert Haas wrote:
> On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund wrote:
> > So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
> > spinlocks for that purpose - no idea where that is true these days.
> Me neither, which is exactly the pr
On Fri, Nov 19, 2010 at 3:07 AM, Andres Freund wrote:
> So the complicated case seems to be !defined(HAS_TEST_AND_SET) which uses
> spinlocks for that purpose - no idea where that is true these days.
Me neither, which is exactly the problem. Under Tom's proposal, any
architecture we don't explic
On Thu, Nov 18, 2010 at 11:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm all in favor of having some memory ordering primitives so that we
>> can try to implement better algorithms, but if we use it here it
>> amounts to a fairly significant escalation in the minimum requirements
>> to comp
On Friday 19 November 2010 05:38:14 Tom Lane wrote:
> Robert Haas writes:
> > I'm all in favor of having some memory ordering primitives so that we
> > can try to implement better algorithms, but if we use it here it
> > amounts to a fairly significant escalation in the minimum requirements
> > to
Robert Haas writes:
> I'm all in favor of having some memory ordering primitives so that we
> can try to implement better algorithms, but if we use it here it
> amounts to a fairly significant escalation in the minimum requirements
> to compile PG (which is bad) rather than just a performance
> op
On Thu, Nov 18, 2010 at 5:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
>>> 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
Robert Haas writes:
> On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
>> 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.
>
On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane wrote:
> Heikki Linnakangas 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
Heikki Linnakangas 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 proce
On 15.11.2010 16:51, Tom Lane wrote:
Heikki Linnakangas writes:
I believe it's safe to
assume that two operations using a volatile pointer will not be
rearranged wrt. each other.
This is entirely wrong, so far as cross-processor visibility of changes
is concerned.
Ok.
In SetLatch, is it en
On Mon, Nov 15, 2010 at 9:51 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
Hmm, SetLatch only sets one flag, so I don't see how it could malfunction
all by itself. And I would've thought that declaring the Latch variable
"volatile" prevents rearrangements.
>>>
>>> It's not a que
Heikki Linnakangas writes:
>>> Hmm, SetLatch only sets one flag, so I don't see how it could malfunction
>>> all by itself. And I would've thought that declaring the Latch variable
>>> "volatile" prevents rearrangements.
>>
>> It's not a question of code rearrangement.
Precisely. "volatile" pre
On Mon, Nov 15, 2010 at 8:45 AM, Heikki Linnakangas
wrote:
>> It's not a question of code rearrangement.
>
> Rearrangement of code, rearrangement of CPU instructions, or rearrangement
> of the order the changes in the memory become visible to other processes.
> The end result is the same.
I'll le
On 15.11.2010 15:22, Robert Haas wrote:
On Mon, Nov 15, 2010 at 2:15 AM, Heikki Linnakangas
wrote:
Can you elaborate?
Weak memory ordering means that stores into shared memory initiated by
one processor are not guaranteed to be observed to occur in the same
sequence by another processor. Th
On Mon, Nov 15, 2010 at 2:15 AM, Heikki Linnakangas
wrote:
>>> Can you elaborate?
>>
>> Weak memory ordering means that stores into shared memory initiated by
>> one processor are not guaranteed to be observed to occur in the same
>> sequence by another processor. This implies first that the latc
On 14.11.2010 22:55, Tom Lane wrote:
Heikki Linnakangas writes:
On 13.11.2010 17:07, Tom Lane wrote:
Robert Haas writes:
Come to think of it, I'm not really sure I understand what protects
SetLatch() against memory ordering hazards. Is that actually safe?
Hmm ... that's a good question.
57 matches
Mail list logo
