j******n
发帖数: 271 | 1 Does anyone know if there is a Linux API allowing a single call to
block and wait for multiple condition variables, in a way similar to
select() waiting on multiple fds, and, similar to the Win32 API
WaitForMultipleObjects()? Many thanks! |
X****r
发帖数: 3557 | 2 You can wait for a single condition and allow multiple sources signal
this condition.
【在 j******n 的大作中提到】
: Does anyone know if there is a Linux API allowing a single call to
: block and wait for multiple condition variables, in a way similar to
: select() waiting on multiple fds, and, similar to the Win32 API
: WaitForMultipleObjects()? Many thanks!
|
P********e
发帖数: 2610 | 3 除非能知道是谁signal的，否则好像不太一样
【在 X****r 的大作中提到】
: You can wait for a single condition and allow multiple sources signal
: this condition.
|
X****r
发帖数: 3557 | 4 pthread系列的wait/signal本身不传递数据，所以你反正也要用共享的变量，
加一个谁signal的变量不就行了。
【在 P********e 的大作中提到】
: 除非能知道是谁signal的，否则好像不太一样
|
j******n
发帖数: 271 | 5 That seems to have a problem. When the thread wakes up from the wait and
checks the variable identifying the sender of signal, it still cannot be
sure
that no other senders also signals the condition. As a result, it has to
check
all possible sources. One example is:
consumer waits on a condition;
sender 1 signals the condition and marks the sender id as 1;
consumer wakes up but preempted before doing anything
sender 2 signals the condition and marks the sender id as 2;
consumer continues and ch
【在 X****r 的大作中提到】
: pthread系列的wait/signal本身不传递数据，所以你反正也要用共享的变量，
: 加一个谁signal的变量不就行了。
|
t****t
发帖数: 6806 | 6 if multiple src are allowed to signal simutaneously, the "variable" must
allow this, of course.
【在 j******n 的大作中提到】
: That seems to have a problem. When the thread wakes up from the wait and
: checks the variable identifying the sender of signal, it still cannot be
: sure
: that no other senders also signals the condition. As a result, it has to
: check
: all possible sources. One example is:
: consumer waits on a condition;
: sender 1 signals the condition and marks the sender id as 1;
: consumer wakes up but preempted before doing anything
: sender 2 signals the condition and marks the sender id as 2;
|
X****r
发帖数: 3557 | 7 It is not a problem, because pthread_cont_wait automatically locks
the mutex before it returns. As long as you always access the variable
after obtained the mutex -- you must do it to make sure the wait
performs correctly anyway -- there is not problem.
【在 j******n 的大作中提到】
: That seems to have a problem. When the thread wakes up from the wait and
: checks the variable identifying the sender of signal, it still cannot be
: sure
: that no other senders also signals the condition. As a result, it has to
: check
: all possible sources. One example is:
: consumer waits on a condition;
: sender 1 signals the condition and marks the sender id as 1;
: consumer wakes up but preempted before doing anything
: sender 2 signals the condition and marks the sender id as 2;
|
j******n
发帖数: 271 | 8 The problem is not about locking the variable or not. It is about you cannot
reliably detect *ALL* senders using a simple variable to identify the sender
.
One can use a struct such as a list to store the sender ids. Then there is
the
problem that when the consumer is too slow, the list may grow unbounded.
【在 X****r 的大作中提到】
: It is not a problem, because pthread_cont_wait automatically locks
: the mutex before it returns. As long as you always access the variable
: after obtained the mutex -- you must do it to make sure the wait
: performs correctly anyway -- there is not problem.
|
t****t
发帖数: 6806 | 9 the send id should be something like a bit map, such as the one used in
select(2). no one will use a list to describe that.
cannot
sender
【在 j******n 的大作中提到】
: The problem is not about locking the variable or not. It is about you cannot
: reliably detect *ALL* senders using a simple variable to identify the sender
: .
: One can use a struct such as a list to store the sender ids. Then there is
: the
: problem that when the consumer is too slow, the list may grow unbounded.
|
