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, [EMAIL PROTECTED] wrote:
Message: 3
Date: Thu, 20 Oct 2005 23:07:12 +0200
From: Alexander Malmberg <[EMAIL PROTECTED]>
Subject: Re: An acutal NSLock bug
To: Bug GNUstep <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
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
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
