Re: Question about NSThread?
Re: Question about NSThread?
- Subject: Re: Question about NSThread?
- From: Kai <email@hidden>
- Date: Wed, 19 Nov 2008 23:11:20 +0100
It depends...
You may well just be lucky that it seems to work (or unlucky, this
again depends...).
If your worker thread is only reading any data shared with other
threads, it will indeed never disturb these other threads (probably
just the main thread in your case). But if the main thread modifies
this data, your worker thread may get inconsistent values. Like
reading the width, then the main thread modifies the size (both width
and height), then the worker thread reads the height.
The simplest approach would be to give the worker thread the complete
info it needs at once when it is started, thus avoiding any shared data.
NSOperation and NSOperationQueue might be of help here. You would
create a sub class of NSOperation which knows all the info your worker
thread needs and off you go.
Best luck
Kai
On 19.11.2008, at 22:37, Jean-Nicolas Jolivet wrote:
Mmm I see....
Well, right now I would say my worker thread is pretty much just
reading values (size of image to generate etc)... but it's not
"modifying" anything... it doesn't change any variables etc... just
reads the info it needs to generate the images and ...well,
generates the images...
If my worker thread doesn't have to "write" in any variables/objects
whatever, shared with the UI, can I assume that it's safe to leave
it like it is?
On 19-Nov-08, at 4:32 PM, Stefan Sinclair wrote:
In a word, yes :)
If you are accessing a piece of memory across threads, you should
be making sure you are synchronizing any access to that memory
which could occur across threads. For simple primitives (such as
possibly your work progress number) just using an atomic integer
would suffice. For more complicated access, you will want better
protection (such as using locks around any APIs which can access
your data). You're probably getting away with it now b/c your UI
thread (the main thread) is only reading data (the work progress
value - I'm guessing a single integer or floating point value which
can be read/written in a single instruction) while the worker
thread is modifying it. But it doesn't hurt to use proper thread-
safe access patterns for data shared between threads even for small
things like this.
-Stefan
> From: email@hidden
> To: email@hidden
> Date: Wed, 19 Nov 2008 15:57:44 -0500
> Subject: Question about NSThread?
>
> I have an app that generates a bunch of images... the process can
be
> long so I wanted to start it in a separate thread so that the UI
can
> be responsive etc...
>
> basically the only thing I did was:
>
> [NSThread detachNewThreadSelector:@selector(doLongProcess)
> toTarget:self withObject:nil];
>
> and I added
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>
> at the beginning of my doLongProcess method, and [pool release]
at the
> end...
> Now the weird part is that... it appears to be working... the
images
> are created...the UI stays responsive..my status textfield gets
> updated (it wasn't getting updated when the long process was not
in a
> separate thread)...
>
> Am I wrong to think that it should've been much more complex than
> that? (With NSLocks and whatnot...) Maybe I should just shut up
and be
> happy that it work, but somehow this doesn't seem right...
>
> Jean-Nicolas Jolivet
> email@hidden
> http://www.silverscripting.com
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
Proud to be a PC? Show the world. Download the “I’m a PC” Messenger
themepack now. Download now.
Jean-Nicolas Jolivet
email@hidden
http://www.silverscripting.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden