pgsql: De-pessimize ConditionVariableCancelSleep(). - Mailing list pgsql-committers

From Thomas Munro
Subject pgsql: De-pessimize ConditionVariableCancelSleep().
Date
Msg-id E1qVgKA-000Aef-Tu@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
De-pessimize ConditionVariableCancelSleep().

Commit b91dd9de was concerned with a theoretical problem with our
non-atomic condition variable operations.  If you stop sleeping, and
then cancel the sleep in a separate step, you might be signaled in
between, and that could be lost.  That doesn't matter for callers of
ConditionVariableBroadcast(), but callers of ConditionVariableSignal()
might be upset if a signal went missing like this.

Commit bc971f4025c interacted badly with that logic, because it doesn't
use ConditionVariableSleep(), which would normally put us back in the
wait list.  ConditionVariableCancelSleep() would be confused and think
we'd received an extra signal, and try to forward it to another backend,
resulting in wakeup storms.

New idea: ConditionVariableCancelSleep() can just return true if we've
been signaled.  Hypothetical users of ConditionVariableSignal() would
then still have a way to deal with rare lost signals if they are
concerned about that problem.

Back-patch to 16, where bc971f4025c arrived.

Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/2840876b-4cfe-240f-0a7e-29ffd66711e7%40enterprisedb.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/5ffb7c775062ef18756e515ac96f06d012cbb950

Modified Files
--------------
src/backend/storage/lmgr/condition_variable.c | 16 ++++++----------
src/include/storage/condition_variable.h      |  2 +-
2 files changed, 7 insertions(+), 11 deletions(-)


pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgsql: doc: PG 16 relnotes: udpate for commits since branching
Next
From: Thomas Munro
Date:
Subject: pgsql: De-pessimize ConditionVariableCancelSleep().