\nUnlike mutexes and critical sections,\nsemaphores don’t have owners.\nThey merely have counts.\n<\/P>\n
\n\nThe \n\nSome people use semaphores in a mutex-like manner<\/A>:\nThey create a semaphore with initial count 1 and\nuse it like this:\n<\/P>\n \nIf the thread exits (or crashes) before it manages to release the semaphore,\nthe semaphore counter is not automatically restored.\nCompare mutexes, where the mutex is released if the owner thread\nterminates while holding it.\nFor this pattern of usage, a mutex is therefore preferable.\n<\/P>\n \nA semaphore is useful if the conceptual ownership of a resource\ncan cross threads.\n<\/P>\n DWORD CALLBACK KeepWorking(void* lpParameter)\n{\n … finish working …\n ReleaseSemaphore(hSemaphore, 1, NULL);\n return 0;\n}\n<\/PRE>\n \nThis trick doesn’t work with a mutex or critical section because\nmutexes and critical sections have owners, and only the owner can\nrelease the mutex or critical section.\n<\/P>\n \nNote that if the \nAnother common usage pattern for a semaphore is the opposite of\nthe resource-protection pattern: It’s the resource-generation\npattern. In this model the semaphore count normally is zero,\nbut is incremented when there is work to be done.\n<\/P>\n \/\/ There can be more than one worker thread.\n\/\/ Each time a work item is signalled, one thread will\n\/\/ be chosen to process it.\nDWORD CALLBACK ProcessWork(void* lpParameter)\n{\n for (;;) {\n \/\/ wait for work to show up\n WaitForSingleObject(hSemaphore, INFINITE);\n … retrieve a work item from the work list …\n … perform the work …\n }\n \/\/ NOTREACHED\n}\n<\/PRE>\n \nNotice that in this case, there is not even a conceptual\n“owner” of the semaphore, unless you count the work item itself\n(sitting on a work list data structure somewhere)\nas the owner. If the \n(A higher performance version of the producer\/consumer semaphore\nis the\n\nI\/O completion port<\/A>.)\n<\/P>\nReleaseSemaphore<\/CODE> function<\/A>\nincreases the count associated with a semaphore\nby the specified amount.\n(This increase might release waiting threads.)\nBut the thread releasing the semaphore need not be the same\none that claimed it originally.\nThis is different from mutexes and critical sections,\nwhich require that the claiming thread also be the releasing one.\n<\/P>\n\nWaitForSingleObject(hSemaphore, INFINITE);\n… do stuff ..\nReleaseSemaphore(hSemaphore, 1, NULL);\n<\/PRE>\n
\nWaitForSingleObject(hSemaphore, INFINITE);\n… do some work ..\n… continue on a background thread …\nHANDLE hThread = CreateThread(NULL, 0, KeepWorking, …);\nif (!hThread) {\n … abandon work …\n ReleaseSemaphore(hSemaphore, 1, NULL); \/\/ release resources\n}<\/p>\nKeepWorking<\/CODE> function exits and\nforgets to release the semaphore, then the counter is not\nautomatically restored. The operating system doesn’t know that\nthe semaphore “belongs to” that work item.\n<\/P>\n\n… produce some work and add it to a work list …\nReleaseSemaphore(hSemaphore, 1, NULL);<\/p>\n
ProcessWork<\/CODE> thread exits,\nyou do not<\/STRONG> want the semaphore to be released\nautomatically; that would mess up the accounting.\nA semaphore is an appropriate object in this case.\n<\/P>\n