Take the 2-minute tour ×

I am quite new to multithreading programming and wonder if it is ok or to make a property like

@property BOOL shouldDoIt; //atomic

which will be used in a loop that is called in the background

- (void) loop{
    // ... do stuff ...
    if (self.shouldDoIt) {
        [self doIt];
        self.shouldDoIt = NO;
    // ... do more stuff ...

and changed in a method called from the main thread

- (void) methodCalledFromMainThread{
    self.shouldDoIt = YES;

Do I have to make it atomic or it does not change anything? I know atomic is slow in comparison to nonatomic and my program needs more speed but if not using atomic then doing if (shouldDoIt){ might fail?

share|improve this question

5 Answers 5

up vote 1 down vote accepted

The answer is entirely dependent on the answer to the question:

"do you need to run doIt exactly once for each time the main thread sets the shouldDoIt flag?"

If the answer to that question is "yes" then your code will not work because the main thread might set shouldDoIt to YES after you have started doIt but before you have reset the flag.

If the answer is "no", in this narrow case, what you have is sort of OK excepting the fact that in a multi CPU configuration, the flag might be cached in such a way that the other thread does not immediately see the change. So you probably at least want to use OSAtomicTestAndClearBarrier() and OSAtomicTestAndSetBarrier() which are as low level, hence as fast as you can get.

However, I'm sceptical that you need to do this. I think you might find refactoring the design in some way will get better results depending on what you are trying to do in doIt, do stuff and do more stuff.

share|improve this answer
If we are using only a writer thread and reader thread than we don't need interlocked access to variable shouldDoI of course main thread must first wait shouldDoI to become 0 before set again the shouldDoI. –  GJ. Dec 16 '10 at 17:02
JeremyP you have made me realize the difference between setting back shouldDoIt to NO after and before doIt. +1 for OSAtomicTestAndClear/SetBarrier() ;) –  nacho4d Dec 16 '10 at 18:31

On may thread you have an BOOL that you want to set to no after you do some job in back thread

[NSThread detachNewThreadSelector:@selector(backThreadAction:) toTarget:self withObject:nil];

-(void) backThreadAction:(id*)someObject{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    //do stuff here

    [self performSelectorOnMainThread:@selector(didFinishBackThreadAction:) withObject:nil waitUntilDone:NO];
    [pool release];

-(void) didFinishBackThreadAction:(id *)someObject{
   //set your bool to no
share|improve this answer
+1 for the code ;) I suppose I can do the same with GCD (since I am not using NSThread or performSelectorOn... APIs) –  nacho4d Dec 16 '10 at 18:24

Read first the Threading Programming Guide from Apple and I think you need an NSLock but be careful you can get an deadlock. Good Luck

share|improve this answer
I understand that NSLock is an alternative but I think is too much work and I trying to fin out if 'atomic' is just enough when is a single BOOL flag like this case. –  nacho4d Dec 16 '10 at 16:07
If you set an property atomic it will have mutex locks on setter and getter. In you case if you set the bool to yes and the go to an back thread and do some stuff, and after you do the stuff you will set it to no I don't see any problem here. –  Alex Terente Dec 16 '10 at 16:24

in this part of the code :

if (self.shouldDoIt) {
    [self doIt];

shouldDoIt being atomic does not guarantee that it is still true when you call doIt. You must use a lock to make sure the value did not change after the test and before you actually do what you have to do.

share|improve this answer
Not true, if we are using only a writer thread and reader thread! –  GJ. Dec 16 '10 at 16:47

If you are using only a main thread as writer and second thread as reader than is quite safe! Atomic or interlocked methods are necessary only when two or more threads accessing at once the some variable for rading or writing, that can be heppend in multy core CPU, or if memory wosn't fenced from memory cache.

share|improve this answer
I got the idea, I believe this is my case... but what would happen if two threads were reading the same buffer of memory(lets say an image) at the same time? Since its only reading is ok? –  nacho4d Dec 16 '10 at 18:27
No problem if writers are not present! From that reason exist Slim Read/Write Locks which allow multiple readers xor one writer at once. –  GJ. Dec 16 '10 at 18:35
That only works by coincidence with the data type and is a very dangerous pattern to employ as it lacks future proofness. If you want to do something like this, use GCD queues as they are both extremely fast and avoid the aforementioned issues. –  bbum Dec 16 '10 at 18:45
bbum, I am using blocks and CGD, not NSThreads or performSelectorIn... methods, this means that this should be thread safe? –  nacho4d Dec 16 '10 at 19:18

Your Answer


