Re: Detect double-release of spinlock - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Detect double-release of spinlock
Date
Msg-id 790b901f-c0f6-4e97-b59a-97d8f921d57e@iki.fi
Whole thread Raw
In response to Re: Detect double-release of spinlock  (Andres Freund <andres@anarazel.de>)
Responses Re: Detect double-release of spinlock
List pgsql-hackers
On 29/07/2024 20:48, Andres Freund wrote:
> On 2024-07-29 13:25:22 -0400, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>> Yeah I'm not worried about that at all. Also, the assert is made when
>>> you have already released the spinlock; you are already out of the
>>> critical section.
>>
>> Not in the patch Andres posted.
> 
> Which seems fairly fundamental - once outside of the critical section, we
> can't actually assert that the lock isn't acquired, somebody else *validly*
> might have acquired it by then.

You could do:

bool was_free = S_LOCK_FREE(lock);

S_UNLOCK(lock);
Assert(!was_free);

Depending on the underlying implementation, you could also use 
compare-and-exchange. That makes the assertion-enabled instructions a 
little different than without assertions though.

> However, I still don't think it's a problem to assert that the lock is held in
> in the unlock "routine". As mentioned before, the spinlock implementation
> itself has never followed the "just straight line code" rule that users of
> spinlocks are supposed to follow.

Agreed.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Optimize mul_var() for var1ndigits >= 8
Next
From: Robert Haas
Date:
Subject: Re: Interrupts vs signals