WAIT_EVENT_INTERRUPT(9) Driver Basics WAIT_EVENT_INTERRUPT(9)NAME
wait_event_interruptible - sleep until a condition gets true
SYNOPSIS
wait_event_interruptible(wq, condition);
ARGUMENTS
wq
the waitqueue to wait on
condition
a C expression for the event to wait for
DESCRIPTION
The process is put to sleep (TASK_INTERRUPTIBLE) until the condition evaluates to true or a signal is received. The condition is checked
each time the waitqueue wq is woken up.
wake_up has to be called after changing any variable that could change the result of the wait condition.
The function will return -ERESTARTSYS if it was interrupted by a signal and 0 if condition evaluated to true.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 WAIT_EVENT_INTERRUPT(9)
Check Out this Related Man Page
pthread_cond_signal(3T)pthread_cond_signal(3T)NAME
pthread_cond_signal(), pthread_cond_broadcast() - unblock one or all threads waiting on a condition variable
SYNOPSIS PARAMETERS
cond Pointer to the condition variable to be signaled or broadcast.
DESCRIPTION
The function is used to wake-up one of the threads that are waiting for the occurrence of a condition associated with condition variable
cond. If there are no threads blocked on cond, this function has no effect. If more than one thread is blocked on cond, the scheduling
policy determines which thread is unblocked. It is possible that more than one thread can be unblocked due to a spurious wakeup.
The function is used to wake-up all threads that are waiting for the occurrence of a condition associated with the condition variable cond.
If there are no threads blocked on cond, this function has no effect. If more than one thread is blocked on cond, the scheduling policy
determines the order in which threads are unblocked.
The condition variabled denoted by cond must have been dynamically initialized by a call to or statically initialized with the macro
An unblocked thread will reacquire the mutex it held when it started the condition wait before returning from or The threads that are
unblocked contend for the mutex according to their scheduling policy and priority.
The or functions can be called by a thread whether or not it currently owns the condition variable's associated mutex. For predictable
scheduling behavior and to prevent lost wake-ups, the mutex should be held when signaling a condition variable.
Usage
When using condition variables, there is a boolean predicate associated with each condition wait. If this predicate is false, the thread
should do a condition wait. Spurious wakeups may occur when waiting on a condition variable. Because the return values from and do not
imply anything about the value of this predicate, the predicate should always be re-evaluated.
Applications using condition variables typically acquire a mutex and enter a loop which checks the predicate. Depending on the value of
the predicate, the thread either breaks out of the loop or waits on the condition. On return from the condition wait, the predicate is re-
evaluated.
RETURN VALUE
Upon successful completion, and return zero. Otherwise, an error number is returned to indicate the error (the variable is not set).
ERRORS
For each of the following conditions, if the condition is detected, the and functions return the corresponding error number:
[EINVAL] cond is not a valid condition variable.
[EFAULT] cond parameter points to an illegal address.
AUTHOR
and were derived from the IEEE POSIX P1003.1c standard.
SEE ALSO pthread_cond_init(3T), pthread_cond_wait(3T).
STANDARDS CONFORMANCE
Pthread Library pthread_cond_signal(3T)