An acutal NSLock bug

[Morgan Giddings]

Hi,

I've encountered a new issue with GNUStep's NSLock that I believe is  
a true bug.

If the same thread calls NSLock twice in a row, before that lock is  
unlocked, GNUStep raises the exception:
NSLockException, reason: Thread attempted to recursively lock

But this is not a recursive situation.  It is actually just a loop.   
The point of the code is that the first time through the loop, the  
lock is acquired, and the second time through the loop, I expect it  
to block.  That is all well and good, because one of the children  
that were launched will later call "unlock" which will let the main  
loop proceed again.

here's example pseudocode, which is simplified from the original to  
illustrate the point:

numprocesses=99;
while (numprocesses >= 0) {
    [myLock lock];
    [NSThread detachNewThreadSelector:@selector(doProcess:)  
toTarget:anObject withObject:anotherObject];
    numprocesses --;
}

when the thread launched on "doProcess" is done, it calls  
"threadDone", which has the following pseudocode:

- (void)threadDone
{
    [myLock unlock];
}

In Cocoa, this launches a child thread then on the next time through  
the loop blocks at [myLock lock] until the child thread is done and  
unlocks it.  In GNUStep, this raises an exception.

What's worse is that I cannot just work around this (as I did for the  
unlock problem) by catching this exception, because I need it to block.

I'm inclined to just remove the recursive lock check and submit the  
diffs, but thought I would check here first to see whether anyone  
actually depends on the code raising an exception.

The alternative is to put in a small loop that checks a variable  
periodically to see whether the child thread is done, and sleeps in- 
between checks.  However, this is sub-optimal.  In the case where the  
child threads complete quickly and there are many of them (i.e.  
1000's), we don't want to sit there sleeping for a long time before  
it checks whether a child is done, as this significantly slows down  
the program .  But if we set the sleep interval to be too small, then  
the loop itself eats up a bunch of processor time.  NSLock has been  
ideal for solving this dilemma, if I could only get it to work on  
GNUStep.

Thanks,

Morgan Giddings, Assistant Professor
Departments of Microbiology/Immunology and Biomedical Engineering
UNC-Chapel Hill
919-843-3513, giddings@unc.edu
http://bioinfo.unc.edu/giddings.html