Date: Mon, 11 Aug 2008 12:29:55 -0600
From: Scott Ribe <[EMAIL PROTECTED]>
...but it would surprise if you have to take the lock
just to inspect the condition (per the "threadMustExit" method).
That part is correct, as it's the entire point behind conditions,
atomically
check a condition and release the lock at the same time (and
subsequently
relock)--in order to avoid race conditions between thread a
releasing lock
and checking, and thread b setting...
Which part is correct? The original code? Or my comment?
It's true that for scenarios where one wants to change the condition
as a dependency of the current condition, the
"lock"/"unlockWithCondition" pattern is needed.
But the code posted gains nothing by locking and unlocking while
checking the condition, since it locks unconditionally and doesn't
change the condition state as a result of its inspection. Inasmuch
as a race condition might exist, the code that was posted doesn't
avoid it (note that "race condition" can still happen even when
locking...not all race conditions are bad, they just need to be
accounted for) because in the method I was describing, the lock/
unlock behavior in the code doesn't use the "Condition" part of the
NSConditionLock.
Now, it could be that there's something about how the class maintains
the "condition" property that makes it a bug to not take the lock
before inspection that property. But that would be unusual for an
object specifically designed for thread synchronization, and
especially given that the documentation doesn't mention any
requirement to take the lock before inspecting the property.
Pete
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
