Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
- Subject: Re: detachDrawingThread:toTarget:withObject: vs detachNewThreadSelector:toTarget:withObject:
- From: Antonio Nunes <email@hidden>
- Date: Thu, 28 Sep 2006 09:47:52 +0100
On 28 Sep 2006, at 05:21, Chris Hanson wrote:
The one place in my code where I know problems could occur I've
made thread safe using @synchronize.
The above is either incorrect terminology or not doing what you
think it is. All @synchronize does is declare a critical section
linked to some object: a lock around a section of code such that
only a single thread can be in *that section* of code *for that
object* at the same time.
Thus whether or not the code in your @synchronized block is thread-
safe depends a great deal on what the code actually does, and how
it interacts with the rest of the code in your applciation.
Ah, I get your point. Well, the objective is indeed to make sure that
for the object in question only a single thread has access to that
block of code at a time. The code block itself is small (five lines)
and pretty self contained. (It accesses a PDFPage it has cached to
obtain and store both a data representation of it and a PDFDocument
representing the page.) Since potentially both the main thread and a
secondary thread may need to access the code block for that object at
the same time, it needs the lock.
I have a hard time seeing how the code block itself would have side
effects that would cause crashes in other parts of the code. The
object is (supposedly) always in a valid state. It either has already
converted its cache (prompted by a 'background' thread) when asked to
draw itself and has a valid "source" property, or it hasn't, in which
case it performs the conversion and fills in its "source" before
drawing itself (drawing always happens in the main thread). The cache
is not visible to other objects, and the "source" property is checked
for a nil state when accessed (which currently is only done by the
object itself), or, at worst, a message might get sent to nil, which
would be valid, but that would merely affect drawing, and since the
conversion always happens before the first time the object is asked
to draw itself this situation never arises.
-António
-----------------------------------------
Accepting others as they are
brings a wonderful freedom
to your own mind.
--The Peace Formula
-----------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden