Morgan Giddings wrote: > 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.
Well, the code I gave was equivalent to the code you'd get with the lock semantics you expect (as I understand them, and modulo any mistakes, of course ;), so extending it to multiple threads wouldn't be any problem (with one lock per thread or whatever). To explain a bit more, the "lock" of NS*Lock is just there to protect something from being accessed from more than one thread, so it shouldn't be manipulated from more than one thread at a time. If you want a lock that you can lock and unlock from different threads, you need to think of the state of that lock as the _condition_ of the NSConditionLock, not the actual lock state of NSConditionLock. Thus, replacing 1 and 0 with named constants, we get: >> [lock lockWhenCondition: UNLOCKED]; >> [lock unlockWithCondition: LOCKED]; I.e. blocks until the "lock" (really the condition) is in the unlocked state, and when it is, move it to the locked state. And: >> [lock lockWhenCondition: LOCKED]; >> [lock unlockWithCondition: UNLOCKED]; Blocks until the lock is in the locked state*, and when it is, move it to the unlocked state. (*A bit odd behavior, but unlocking a lock that isn't locked is an odd case; if you want different behavior here, you can use e.g. -lock and -condition directly.) The lock of NSConditionLock just ensures that only one thread at a time can touch the condition. Adam Fedor wrote: > Well, sure, I don't think we should forbid a developer from doing > something crazy if they really want to. Particularly in this case > since there is no work-around when the exception is called. Perhaps > changing the exception to a warning (GSOnceMLog). Any opinions? Well, as far as I can tell, the exception is there to catch misuses caused by the slightly unusual behavior of the NS*Lock classes, and that's what it has done. - Alexander Malmberg _______________________________________________ Bug-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnustep
