2016-11-22 20:26:40 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* condition_variable.h
|
|
|
|
* Condition variables
|
|
|
|
*
|
|
|
|
* A condition variable is a method of waiting until a certain condition
|
|
|
|
* becomes true. Conventionally, a condition variable supports three
|
|
|
|
* operations: (1) sleep; (2) signal, which wakes up one process sleeping
|
|
|
|
* on the condition variable; and (3) broadcast, which wakes up every
|
|
|
|
* process sleeping on the condition variable. In our implementation,
|
|
|
|
* condition variables put a process into an interruptible sleep (so it
|
2020-06-07 15:06:51 +02:00
|
|
|
* can be canceled prior to the fulfillment of the condition) and do not
|
2016-11-22 20:26:40 +01:00
|
|
|
* use pointers internally (so that they are safe to use within DSMs).
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2016-11-22 20:26:40 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* src/include/storage/condition_variable.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef CONDITION_VARIABLE_H
|
|
|
|
#define CONDITION_VARIABLE_H
|
|
|
|
|
|
|
|
#include "storage/proclist_types.h"
|
2020-06-19 04:40:09 +02:00
|
|
|
#include "storage/spin.h"
|
2016-11-22 20:26:40 +01:00
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
2018-01-09 00:28:03 +01:00
|
|
|
slock_t mutex; /* spinlock protecting the wakeup list */
|
|
|
|
proclist_head wakeup; /* list of wake-able processes */
|
2016-11-22 20:26:40 +01:00
|
|
|
} ConditionVariable;
|
|
|
|
|
2021-03-10 22:05:58 +01:00
|
|
|
/*
|
|
|
|
* Pad a condition variable to a power-of-two size so that an array of
|
|
|
|
* condition variables does not cross a cache line boundary.
|
|
|
|
*/
|
|
|
|
#define CV_MINIMAL_SIZE (sizeof(ConditionVariable) <= 16 ? 16 : 32)
|
|
|
|
typedef union ConditionVariableMinimallyPadded
|
|
|
|
{
|
|
|
|
ConditionVariable cv;
|
|
|
|
char pad[CV_MINIMAL_SIZE];
|
|
|
|
} ConditionVariableMinimallyPadded;
|
|
|
|
|
2016-11-22 20:26:40 +01:00
|
|
|
/* Initialize a condition variable. */
|
2018-01-09 00:28:03 +01:00
|
|
|
extern void ConditionVariableInit(ConditionVariable *cv);
|
2016-11-22 20:26:40 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* To sleep on a condition variable, a process should use a loop which first
|
|
|
|
* checks the condition, exiting the loop if it is met, and then calls
|
|
|
|
* ConditionVariableSleep. Spurious wakeups are possible, but should be
|
2018-01-09 00:28:03 +01:00
|
|
|
* infrequent. After exiting the loop, ConditionVariableCancelSleep must
|
2016-11-22 20:26:40 +01:00
|
|
|
* be called to ensure that the process is no longer in the wait list for
|
2018-01-09 17:39:10 +01:00
|
|
|
* the condition variable.
|
2016-11-22 20:26:40 +01:00
|
|
|
*/
|
2018-01-09 00:28:03 +01:00
|
|
|
extern void ConditionVariableSleep(ConditionVariable *cv, uint32 wait_event_info);
|
2019-07-13 03:40:36 +02:00
|
|
|
extern bool ConditionVariableTimedSleep(ConditionVariable *cv, long timeout,
|
|
|
|
uint32 wait_event_info);
|
2016-11-22 20:26:40 +01:00
|
|
|
extern void ConditionVariableCancelSleep(void);
|
|
|
|
|
|
|
|
/*
|
2018-01-09 00:28:03 +01:00
|
|
|
* Optionally, ConditionVariablePrepareToSleep can be called before entering
|
|
|
|
* the test-and-sleep loop described above. Doing so is more efficient if
|
|
|
|
* at least one sleep is needed, whereas not doing so is more efficient when
|
|
|
|
* no sleep is needed because the test condition is true the first time.
|
2016-11-22 20:26:40 +01:00
|
|
|
*/
|
2018-01-09 00:28:03 +01:00
|
|
|
extern void ConditionVariablePrepareToSleep(ConditionVariable *cv);
|
2016-11-22 20:26:40 +01:00
|
|
|
|
|
|
|
/* Wake up a single waiter (via signal) or all waiters (via broadcast). */
|
Remove return values of ConditionVariableSignal/Broadcast.
In the wake of commit aced5a92b, the semantics of these results are
a bit squishy: we can tell whether we signaled some other process(es),
but we do not know which ones were real waiters versus mere sentinels
for ConditionVariableBroadcast operations. It does not help much that
ConditionVariableBroadcast will attempt to pass on the signal to the
next real waiter, because (a) there might not be one, and (b) that will
only happen awhile later, anyway. So these results could overstate how
much effect the calls really had.
However, no existing caller of either function pays any attention to its
result value, so it seems reasonable to just define that as a required
property of a correct algorithm. To encourage correctness and save some
tiny number of cycles, change both functions to return void.
Patch by me, per an observation by Thomas Munro. No back-patch, since
if any third parties happen to be using these functions, they might not
appreciate an API break in a minor release.
Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
2018-01-06 02:33:26 +01:00
|
|
|
extern void ConditionVariableSignal(ConditionVariable *cv);
|
|
|
|
extern void ConditionVariableBroadcast(ConditionVariable *cv);
|
2016-11-22 20:26:40 +01:00
|
|
|
|
|
|
|
#endif /* CONDITION_VARIABLE_H */
|