[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

[Richard Frith-Macdonald]

Follow-up Comment #4, bug #25307 (project gnustep):


> The point of "tryLock" and "tryLockWhenCondition:" is to attempt to do the
> lock and return NO, if it can't.

Sure ... but the rationale was that, if the lock is held by the current
thread then calling it is evidence of a probable bug.
Why?  Because if a thread holds a lock it is also responsible for releasing
the lock ... which means it must know that it holds the lock ...  in which
case there is no need for it to try locking again.
I'm pretty sure that's the rationale behind the current code... though I'm
not sure I consider it valid as I can construct scenarios where you could do
this and not have a bug (though your code might be hard to understand).

>  For it to return an exception seems wrong in any case.  In my opinion it
should
> return NO whether a single thread attempts to lock the same lock twice or
not.

I think it should do whatever MacOS-X does ... but at least we should log a
warning message if a thread tries to obtain a lock twice.

> I believe what we need is a minimal test case to determine how this
behaves
> on Mac OS X.   I will go ahead and write one and attach it here.


Sounds good ... please remember that we should test (and make changes where
necessary) all the locking classes, not just NSConditionLock.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?25307>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/