Thread safety: NSOperationQueue + [array addObject]

Question

I could not find any examples how to deal with the same (class) variable when operation queue is used. In C & threads its about mutexes. So, what happens when NSOperationQueue starts a thread for operation and class variable is modified? Is it thread safe? Thank you.

@interface MyTest {
    NSMutableArray *_array;
}
@end

-(id)init
{
    ...
    _array = [NSMutableArray new]; // class variable

        // queue time consuming loading
    NSOperationQueue *queue = [NSOperationQueue new];
    NSInvocationOperation *operation =
        [NSInvocationOperation initWithTarget:self
                                     selector:@selector(populate)
                                       object:nil];
    [queue addOperation:operation];

        // start continuous processing
    [NSTimer scheduledTimerWithTimeInterval:0.1
                                     target:self
                                   selector:@selector(processing)
                                   userInfo:nil
                                    repeats:YES];
    ...
}

-(void)populate
{
    while (...)
    {
        id element = ...; // time consuming

            // modify class variable "_array" from operation's thread (?)
        [_array addObject:element];

            // Ok, I can do instead of addObject
            // performSelectorOnMainThread:withObject:waitUntilDone:
            // but is it the only way? Is it needed?
    }
}

    // access and/or modify class variable "_array"
-(void)processing
{
    NSLog(@"array.count = %d", array.count);
    for (id i in _array)
    {
        [_array addObject:[NSNumber numberWithInt:rand() % 100]];
            // etc...
    }
}

Daniel · Accepted Answer · 2011-12-22T00:02:03.107

1

No, this is not thread safe, if you start a thread that does some work on a class variable that can be modified by some other thread then its not thread safe, if processing is called from some thread while populate is running on another then you might get an exception when the foreach loop sees that the array has been modified, though you will get that exception anyway as you are modifying the array inside the foreach loop in your example (you shouldnt do that, and the program will throw an exception )... One way to get around this can be with a synchronized block on the array, it will ensure that the synchronized blocks wont be executed at the same time, the thread blocks until one synchronized block finishes, for example

    -(void)populate
    {


        while (...)
        {
            id element = ...; // time consuming

                // modify class variable "_array" from operation's thread (?)
      @synchronized(_array)
        {
            [_array addObject:element];

        }          // Ok, I can do instead of addObject
                // performSelectorOnMainThread:withObject:waitUntilDone:
                // but is it the only way? Is it needed?
        }

    }

        // access and/or modify class variable "_array"
    -(void)processing
    {


          @synchronized(_array)
         {
            NSLog(@"array.count = %d", array.count);
            for (id i in _array)
            {
                //you shouldnt modify the _array here you will get an exception
                    // etc...
            }
        }
    }

edited Dec 22 '11 at 00:02

answered Dec 21 '11 at 23:56

Daniel

22,363
9
64
71

Ok, this is clear. Why this is not written in ConcurrencyProgrammingGuide (the one about Operations/Queues) on Apple's site? I mean, this is the first time I see this `@synchronized`. I see now, that it is described in section about threads. – debleek63 Dec 22 '11 at 00:03
And what is a better practice in your opinion: use `@synchronized` or call `performSelectorOnMainThread`? – debleek63 Dec 22 '11 at 00:05
And another thing: is it an option to declare/access `_array` as `atomic` property? – debleek63 Dec 22 '11 at 00:07
Well calling performOnMainThread will block the main thread if the operation takes a long time, so I wouldnt do that... Also atomic makes no guerantees about thread safety, only the access to the property, once you have the reference you can do non-thread safe stuff to it, check out this answer about that http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties – Daniel Dec 22 '11 at 00:12
Although Apple even points out there's no real advantage to running a synchronized block over a for loop. Generally speaking, if you are looking to chew on some data in a for loop, pass a local variable into your block and only make changes to globally shared data after the operation queue is empty. ```[queue operationCount] < 1``` – newshorts Apr 23 '14 at 08:24
The "@synchronized" will indeed make you thread-safe, but at the same time, it will make your multi-threading useless, since most of the work in the pseudo-code presented, is all about storing/retrieving things from that Array. @synchronized is a patch over a hole in the design. A better approach would be to have a separate synchronous operation queue that all _array modifying actions will flow through. These actions can be then performed sync/async depending on the need of the caller. – Motti Shneor Mar 12 '19 at 09:44
@MottiShneor how is it making it useless? It depends on how you are using it really.. Sync over operations such as modifying an array (add/remove) that take little time are negligable if you are threading long running processes- so using synchronized will very much not make anything "useless"... If i multithread my operation that can take 30 minutes to process, and I synchronize over array mods, the job is very much useful in saving a lot of time – Daniel Mar 12 '19 at 16:04

Thread safety: NSOperationQueue + [array addObject]

1 Answers1

Linked