Alexander Terekhov schrieb:
Roland Schwarz wrote: [...]
Altough I would very much appreciate if someone could tell me why it is not a problem when the sequence: "wait then signal" does occur, during the gate is closed. It might very well be that this indeed _is_ no problem, I just can't see why.
Because incoming waiter holds external mutex while waiting on gate.
This means that there can be at most only one thread beeing blocked on the gate, correct? But this still doesn't me get going. I am considering the following sequence of events: Given sem_wait(semBlockQueue) currently is waiting with nWaitersBlocked == N. The gate is open. 1) signal all takes place, causing closing the gate nWaitersBlocked = 0 nWaitersToUnblock = N 2) sem_wait is getting awake and starts procssing, needing some time to proceed while the gate is closed 3) a new waiter arrives while the gate still is closed he will block on the gate and not increment nWaitersBlocked yet 4) a signal arrives, while gate still is closed Now is 0 < nWaitersToUnblock < N, correct? But 0 == nWaitersBlocked the signal results in a NO-OP and consequently the waiter from 3) will never get it to see - hence it is lost ?? I am studying the pthread_cond_wait.c pseudo code taken from SNAPSHOT 2004-05-16. What do I miss here? I see this is not going to happen if the thread that signals, is holding the external mutex when trying to signal. But this isn't a requirement, is it? Thank you for your kind help. Roland