|
To cite from the v17 docs on the NOTIFY SEMAPHORE statement:
In case several connections are blocked by that semaphore (say, a consumer-producer model with several consumers waiting on the producer to bring out another piece of work), is there a particular order on which connection will be notified - the one that has been blocked as first? |
|
When there is more than one connection blocked on a semaphore the connection that was blocked first is the one that is unblocked. Sorry, I should have asked it in one go: Is the same true (i.e. a FIFO order) for several connections waiting on the same mutex? (Aside: I'm primarily asking as these rules are different for Win32 sync objects: AFAIK there is no guaranteed order.)
(23 Nov '15, 14:20)
Volker Barth
Replies hidden
No, the rules are different if more than one connection is being released: if there are more than one connection then all waiters are woken up and it is a race to see which one(s) get the semaphore. I.e. no strict ordering.
(23 Nov '15, 14:39)
Mark Culp
You say they are all woken up and then all but one will be suspended/locked, again? - Is this noticeable from "outside"? (I would think LOCK MUTEX IN EXCLUSIVE MODE is an atomic operation?)
(23 Nov '15, 14:44)
Volker Barth
2
The "all woken up" behavior is for a NOTIFY SEMAPHORE ... INCREMENT BY num with num > 1. In case of a mutex being RELEASEd, the observed behavior will depend on whether the next connection in line requires a shared or an exclusive lock. If the next connection (first in line) requires a shared lock, then all other connections waiting for a shared lock will also be woken up. If exclusive lock is required, the first-in-queue connection will acquire the lock.
(23 Nov '15, 16:35)
Elmi Eflov
OK, so for mutexes, there is a strict ordering, too. And particular thanks for the details w.r.t. to share mode!
(24 Nov '15, 07:43)
Volker Barth
|
