Re: NSLock behavior

[Morgan Giddings]

Hi,

Well, it is kind of complicated to explain, but basically we were  
using the lock to prevent the launching of too many sub-threads.  We  
have some number of computations to do (e.g. say 100), and the way  
this works is that we launch some number of child threads (say, 2,  
since we have 2 processors on most of our machines), and then block  
the main thread using NSLock until one of the children completes,  
calling a method that then unblocks the lock.  Because OS X did not  
raise an exception upon multiple calls to [<NSLock> unlock], we could  
just have each child thread call unlock, regardless of whether the  
other one had called it or not, hence allowing the main thread to  
advance, which launches another child.  Yeah, it's kind of  
complicated, but it worked well, and avoided having to keep one  
thread looping and/or using timers, which would waste some CPU cycles.

However, rather than waiting for a GNUstep fix, I re-wrote the code  
so that it makes sure that all lock/unlocks are balanced.  It is not  
yet debugged under OSX, and once I get it working there will I try  
GNUStep again.

BTW - it does seem odd that there is no method to check whether a  
lock is locked, but a hack that addresses this (in Cocoa) is to do  
[NSLock description] and then search for the YES/NO string  
corresponding to "locked".  However, I don't like relying on this  
hack, since it seems likely to change in future releases of the OS.

Not that my opinion matters much, since I haven't been a frequent  
contributor to GNUStep in the past, but I believe that when  
implementing undocumented/unspecified behaviors, it would be best to  
match the behavior of Cocoa, because doing so greatly eases porting.   
I have wanted to port this code for several years now, and it is this  
precise issue which has held the port up. I've had two different  
students attempt to bring the code to GNUStep, but because of their  
lack of experience, when they ran into this they didn't get any  
further.  Now I'm doing it myself....  Anyway, I think that making  
ports from Cocoa to GNUStep easy (or even trivial) would be the best  
thing that could be done to increase the number of apps targeted to  
GNUStep.

Morgan

On Oct 19, 2005, at 1:04 PM, bug-gnustep-request@gnu.org wrote:

> Date: Tue, 18 Oct 2005 13:23:54 -0600
> From: Adam Fedor <fedor@doc.com>
> Subject: Re: NSLock behavior
> To: Bug GNUstep <bug-gnustep@gnu.org>
> Message-ID: <456f8eac06ae55d4b11b344025dab292@Denali.local>
> Content-Type: text/plain; charset="us-ascii"; format="flowed"
>
> On 2005-10-18 01:05:19 -0600 Richard Frith-Macdonald
> <richard@brainstorm.co.uk> wrote:
>
>
> > I don't think the OpenStep specification actually says what -unlock
> > should do
> > in the case where a lock can't be unlocked ... so I'd call it a
> > difference in
> > the implementation rather than interpretation.
> >
> > Normally, I'd say we should change the GNUstep implementation to
> > match that
> > of MacOS-X, however my feeling in this case is that maybe we
> > shouldn't.  You
> > have to ask yourself ... why should code be attempting to unlock
> > something
> > that it hasn't locked?  Generally the unbalanced use of locks
> > indicates a
> > severe bug in a program ... so raising an exception  when locks are
> > misused
> > seems like a better idea than letting it pass.  Is the 'better'
> > behavior of
> > GNUstep sufficient to outweigh the implementation differewnce from
> > MacOS-X?
> >
> > What do other people think?
>
>
> I wonder where you would get into a situation where you didn't know if
> a lock had been applied or not? Apparently that may be the case
> here....