* Tom Lane <[EMAIL PROTECTED]> [001205 07:43] wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > Here's the log, the number in parens is the address of the lock,
> > on tas() the value printed to the right is the value in _ret,
> > for the others, it's the value before the lock count is set.
>
> This looks to be the trace of a SpinAcquire()
> (see src/backend/storage/ipc/spin.c):
Yes, those are my debug printfs :).
> > tas (0x30048048) -> 0
> > tas (0x3004804d) -> 0
> > tas (0x3004804c) -> 0
> > S_UNLOCK: (0x30048048) -> 1
>
> followed by SpinRelease():
>
> > tas (0x30048048) -> 0
> > S_UNLOCK: (0x3004804c) -> 1
> > S_UNLOCK: (0x3004804d) -> 1
> > S_UNLOCK: (0x30048048) -> 1
>
> followed by a failed attempt to reacquire the same SLock:
>
> > tas (0x30048048) -> 0
> > tas (0x3004804d) -> 4
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
> > tas (0x3004804d) -> 1
>
> And that looks completely broken :-( ... something's clobbered the
> exlock field of the SLock struct, apparently. Are you sure this
> kernel feature you're trying to use actually works?
No I'm not sure actually. :) I'll look into it further, but I
was wondering if there was something I could do to debug the
locks better. I think I'll add some S_MAGIC or something in
the struct to see if the whole thing is getting clobbered or
what... If you have any suggestions let me know.
> BTW, if you're wondering why an SLock needs to contain *three*
> hardware spinlocks, the answer is that it doesn't. This code has
> been greatly simplified in current sources...
It did look a bit strange...
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
