Re: An actual NSLock bug

[Morgan Giddings]

Thanks Alex and Adam for the discussion/suggestions.

While I had considered using NSCondition locks, it is not yet clear  
to me how I could extend this to launch an arbitrary number of  
simultaneous processes.  In the code I showed you there was the  
simplifying assumption that only one child thread would run at a  
time.  However, in the real code, we actually determine the number of  
processors on the machine, then launch a number of child threads  
equal to that.  Now, it might work to have a rotating set of  
conditions that is dependent on both numprocesses and the actual  
number running at the time (numRunningThreads)... but this is getting  
quite complicated.  The current code, for OSX, is actually quite  
simple, and works great. (but as you point out, by relying on  
undocumented features)

Though it is true that Apple points out the possibility of deadlock,  
they do not raise an exception.  I suppose the question is this: do  
we want to limit the programmer's behavior by raising an exception  
because they  _might_ cause a problem in their code (the handholding  
approach), or should we assume they will do their programming to  
avoid things like deadlocks (the libertarian approach)?  It seems to  
me there are many things in Obj-c which are not aimed at  
handholding.  The memory management comes to mind foremost (every one  
of the programmers I've hired has had problems with this initially  
which I've had to clean up after - no hand-holding there).  So it  
seems a bit odd to me that, in the case of NSLocks, we would assume  
that the programmer needs to be told how to use them (or not), and if  
we *think* they are not using them properly, to raise an exception.   
I believe a deadlock situation as might be caused by improper use of  
NSLocks would be relatively easy to debug compared to obscure memory  
leaks.

To that end, in my  own version of Gnustep, I commented out a single  
line in NSLock that does the check, and this part of the code works  
fine (though there are some other issues still).  I would rather move  
forward with this port, and get the software (gfs.unc.edu) out there  
to people on Windows and Linux, than to be held up further by this  
issue... but, if I still haven't convinced anyone, I suppose at some  
point I will have to come back and deal with this...

Thanks
Morgan


On Oct 21, 2005, at 12:32 PM, bug-gnustep-request@gnu.org wrote:

> Message: 3
> Date: Thu, 20 Oct 2005 23:07:12 +0200
> From: Alexander Malmberg <alexander@malmberg.org>
> Subject: Re: An acutal NSLock bug
> To: Bug GNUstep <bug-gnustep@gnu.org>
> Message-ID: <43580700.8070009@malmberg.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Adam Fedor wrote:
>
> > That being said, I could see how this type of usage could be
> > beneficial. Although I do not know if the underlying thread mechanism
> > supports this.  I would suspect Condition Locks to be better used
> > here (Unfortunately, GNUstep has the same limitation with
> > NSConditonLock locks, which I am definitely more inclined to change,
> > if it is possible using the underlying thread mechanism).
>
> This isn't really a limitation when using NSConditionLock:s (and I
> believe the behavior is intentional), it just makes it a bit less
> obvious how to do this. What you need is something like (untested):
>
>   lock = [[NSConditionLock alloc] initWithCondition: 1];
> ...
>   numprocesses=99;
>   while (numprocesses >= 0)
>   {
>       [lock lockWhenCondition: 1];
>       [lock unlockWithCondition: 0];
>       [NSThread detachNewThreadSelector:@selector(doProcess:)
> toTarget:anObject
>  withObject:anotherObject];
>      numprocesses --;
>   }
> ...
> -(void) doProcess: ...
> {
>   [lock lockWhenCondition: 0];
>   [lock unlockWithCondition: 1];
> ...
> }
>
> - Alexander Malmberg