Usenet Thread: Counting semaphore
> - Does this kernel object adjusts reference count to reflect abandonment by
> one of the processes
Closing a handle and changing the reference count are two different things.
You might imagine a situation where there is a system-wide semaphore that is waited on by 9 processes and set to its intial value by a 10th. The 10th process would have only one job - to set the initial count of the semaphore and exit, but the programmer is sloppy so CloseHandle will not be called before exit. The other 9 processes would then contend for access to the semaphore based on the initial value.
So you can see that it would be conceptually inappropriate for the OS to adjust the reference count simply because the handle was not closed.
Another way to look at it is to imagine that a process incremented a sempahore 560 times, decrements 100, increments, 50, and decrements 70. Should the OS know to knock off 440 on the semaphore when the process exits? What happens if, at the point of abnormal termination, the semaphore is zero because the other processes snarfed all the counts? Should the OS make the value -460?