On Wed, 2010-01-06 at 13:51 -0500, Dale Worley wrote: > On Wed, 2010-01-06 at 13:47 -0500, Scott Lawrence wrote: > > Why not just use the underlying OsBSem in the first place? It's exactly > > what you just did - the only advantage of OsLock is that it releases > > based on the scope. > > And that is the advantage I want to preserve: If control goes out of > the block, the semaphore is released automatically. Having been bitten > by this once (and it took weeks to find the problem), I want to preserve > that safety net.
I think it's a bad idea because it makes the lock scope ambiguous. If I've got a block with an OsLock at the top, I don't want it to be possible that anywhere in that block is not holding the lock (the reverse bug from the one that bit you). If you have the more complex requirement (and clearly that happens), then don't use OsLock at all - use the underlying primitives with explicit acquire and release calls, and get three other smart people to help you look for locking problems. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
