On (31 Aug 97) Darin Mcbride wrote to Jerry Coffin...
 JC> Actually, I am...now.  When I first wrote the code, I wasn't, and
 JC> by the time I realized my error, it would have been a pain to
 JC> change.
 DM> Hmmm... when I looked at the code, it didn't look too bad to switch...
 DM> mind you, I probably have a little more experience with OS/2
 DM> semaphores, so it'd just look easier to me.  :-)
The problem wouldn't have been in changing the class itself.  It would
have been in changing the code that depended upon the class...
 DM> The actual code is an IsClaimed() function to see if the currently
 DM> running thread owns the semaphore.  It's primarily for assertions -
 DM> make sure that we are currently inside our semaphore... i.e.
 DM> template 
 DM> class SafeQueue
 DM> {
 DM> // ...
 DM> private:
 DM>   DoPush(const T& t)
 DM>   {
 DM>     assert(GetSemaphore().IsClaimed());
 DM>     ...
 DM>   }
 DM> // ...
 DM> };
 DM> Any code calling DoPush should have already claimed the semaphore
 DM> before calling DoPush().
Hmm...presumably, there's a public Push() that's basically something
like:
Push(const T &t) {
    GetSemaphore().Claim();
    DoPush(t);
    GetSemaphore().Release();
}
?  Offhand, it doesn't seem like the fact that a semaphore is involved
should be part of the interface.
However, this leave a question in my mind as to whether it makes sense
to separate obtaining the semaphore from the code that accesses the
resource protected by that semaphore.  I'm not sure it wouldn't be
better to simly merge the two instead of trying to ensure that it has
happened with an assert.
 DM> That is the ONLY reason I have for it.  I do NOT have a "who owns
 DM> it?" function.  If you want to know if someone else has it, try to
 DM> claim with a 0 timeout... but it doesn't tell who.
Ah, that at least eliminates the danger of any kind of race condition.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------