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, [EMAIL PROTECTED] wrote:
Date: Tue, 18 Oct 2005 13:23:54 -0600
From: Adam Fedor <[EMAIL PROTECTED]>
Subject: Re: NSLock behavior
To: Bug GNUstep <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
On 2005-10-18 01:05:19 -0600 Richard Frith-Macdonald
<[EMAIL PROTECTED]> 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....
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
