Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6 - Mailing list pgsql-hackers

From dg@illustra.com (David Gould)
Subject Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Date
Msg-id 9804020706.AA09951@hawk.illustra.com
Whole thread Raw
In response to Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6  (Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO>)
List pgsql-hackers
Tom Ivar Helbekkmo:
> * David Gould
> |
> | What do you mean "now with the return values from tas() swapped"? I think
> | your code looks ok, but just want to be sure we are following the same
> | grand plan...
>
> I just meant that my original code (which has been posted before) had
> the tas() function implemented so that it returned 0 on failure, not
> on success, as you asked for.  Thus, I had to swap the sense of the
> return value.  In practice, I changed
>
>     clrl r0            ; clear register r0
>     bbssi $0,(%1),1f    ; branch on bit set else set
>     incl r0            ; increment register r0
> 1:    movl r0,%0        ; return register r0
>
>     [...]
>
> #define    S_LOCK(addr)        do { while (!tas(addr)) ; } while (0)
>
> ...into...
>
>     movl $1, r0        ; set register r0 to 1
>     bbssi $0,(%1),1f    ; branch on bit set else set
>     clrl r0            ; clear register r0
> 1:    movl r0,%0        ; return register r0
>
>     [...]
>
> #define    S_LOCK(addr)        do { while (tas(addr)) ; } while (0)
>

Thats what I thought, but it has been a few years (not saying how many ;-) )
since I wrote any Macro-32 so I figured I should check.

The tas() definition is not to return success or failure so much as to
return the _previous_state_ of the lock. So if you test_and_set the lock
the test part returns true if it was previously locked and false if it was
unlocked. In either case, it is locked after the tas() (the set part).
Only, if it was previously unlocked, someone else owns the lock so we
have to wait for them to unlock it.

-dg

David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - Linux. Not because it is free. Because it is better.



pgsql-hackers by date:

Previous
From: hkkang@aiit.or.kr
Date:
Subject: [Q]process for 'contains'.
Next
From: "Vadim B. Mikheev"
Date:
Subject: Re: [HACKERS] Reminder: Indices are not used