On Monday, 3 July 2000 at 16:59:09 -0700, Joe Eykholt wrote:

I need to look at the implementation more carefully. My understanding is that the mutexes allow exactly one process to run, independent of the number of processors (or any other resource on which they're waiting). If we can allow multiple (but a finite number of) processes to run concurrently, then we should be using counting semaphores (which are, in fact, very similar to sleeping mutexes).

You'll always find good and bad examples. It's difficult to generalize.

If we have a certain number of slots available, then we wake that many. Normally, though, if you're sleeping at all, you've used up all your slots. Consider a counting semaphore which allows four concurrent processes to enter. Initially the counter is set to 4.

- process 1 takes semaphore. Counter goes to 3. - process 2 takes semaphore. Counter goes to 2. - process 3 takes semaphore. Counter goes to 1. - process 4 takes semaphore. Counter goes to 0. - process 5 tries to take semaphore. Counter goes to -1, so process 5 sleeps. - process 6 tries to take semaphore. Counter is -1, so process 6 sleeps. - process 2 releases semaphore. Counter goes to 0. It's still not > 0, so nothing further happens. - process 1 releases semaphore. Counter goes to 1. Process 5 gets scheduled, decreasing counter to 0.

I'm making assumptions about the exact counter implementation and that process 5 gets scheduled, and not process 6, but they're not relevant to the discussion. Clearly at this point, it wouldn't make any sense to try to schedule process 6, since the counter won't allow it. Things might be slightly different if:

- process 1 releases semaphore. Counter goes to 1. *interrupt* - process 3 releases semaphore. Counter goes to 2. Process 5 gets scheduled, decreasing counter to 1. *return from interrupt* - Counter is 1, so process 6 gets scheduled, decreasing the counter to 0.

Clearly at this point, if we had a process 7 waiting on the queue, it wouldn't make any sense to have it scheduled too.

Greg

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message