Locking an object from being accessed by multiple threads - Objective-C

Question

I have a question regarding thread safety in Objective-C. I've read a couple of other answers, some of the Apple documentation, and still have some doubts regarding this, so thought I'd ask my own question.

My question is three fold:

Suppose I have an array, NSMutableArray *myAwesomeArray;

Fold 1:

Now correct me if I'm mistaken, but from what I understand, using @synchronized(myAwesomeArray){...} will prevent two threads from accessing the same block of code. So, basically, if I have something like:

-(void)doSomething {
    @synchronized(myAwesomeArray) {
        //some read/write operation on myAwesomeArray
    }
}

then, if two threads access the same method at the same time, that block of code will be thread safe. I'm guessing I've understood this part properly.

Fold 2:

What do I do if myAwesomeArray is being accessed by multiple threads from different methods? If I have something like:

- (void)readFromArrayAccessedByThreadOne {
    //thread 1 reads from myAwesomeArray
}

- (void)writeToArrayAccessedByThreadTwo {
    //thread 2 writes to myAwesomeArray
}

Now, both the methods are accessed by two different threads at the same time. How do I ensure that myAwesomeArray won't have problems? Do I use something like NSLock or NSRecursiveLock?

Fold 3:

Now, in the above two cases, myAwesomeArray was an iVar in memory. What if I have a database file, that I don't always keep in memory. I create a databaseManagerInstance whenever I want to perform database operations, and release it once I'm done. Thus, basically, different classes can access the database. Each class creates its own instance of DatabaseManger, but basically, they are all using the same, single database file. How do I ensure that data is not corrupted due to race conditions in such a situation?

This will help me clear out some of my fundamentals.

Declare

@synchronize prevents other threads from accessing the same variable that you have locked, not that specific block of code. – Squish

Ah. I see. Well, I guess there was a little more to what I had understood about the @synchronize directive. Thanks! :D – Declare

@Declare I answered your question at https://mcmap.net/q/426671/-does-synchronized-guarantees-for-thread-safety-or-not Kinda. – Tareyn

Answer 1

Fold 1 Generally your understanding of what @synchronized does is correct. However, technically, it doesn't make any code "thread-safe". It prevents different threads from aquiring the same lock at the same time, however you need to ensure that you always use the same synchronization token when performing critical sections. If you don't do it, you can still find yourself in the situation where two threads perform critical sections at the same time. Check the docs.

Fold 2 Most people would probably advise you to use NSRecursiveLock. If I were you, I'd use GCD. Here is a great document showing how to migrate from thread programming to GCD programming, I think this approach to the problem is a lot better than the one based on NSLock. In a nutshell, you create a serial queue and dispatch your tasks into that queue. This way you ensure that your critical sections are handled serially, so there is only one critical section performed at any given time.

Fold 3 This is the same as Fold 2, only more specific. Data base is a resource, by many means it's the same as the array or any other thing. If you want to see the GCD based approach in database programming context, take a look at fmdb implementation. It does exactly what I described in Fold2.

As a side note to Fold 3, I don't think that instantiating DatabaseManager each time you want to use the database and then releasing it is the correct approach. I think you should create one single database connection and retain it through your application session. This way it's easier to manage it. Again, fmdb is a great example on how this can be achieved.

Edit If don't want to use GCD then yes, you will need to use some kind of locking mechanism, and yes, NSRecursiveLock will prevent deadlocks if you use recursion in your methods, so it's a good choice (it is used by @synchronized). However, there may be one catch. If it's possible that many threads will wait for the same resource and the order in which they get access is relevant, then NSRecursiveLock is not enough. You may still manage this situation with NSCondition, but trust me, you will save a lot of time using GCD in this case. If the order of the threads is not relevant, you are safe with locks.

Abel

Thanks a ton for your reply! I guess this takes care of most of my doubts. Just as a confirmation: I'm guessing I'd be using an NSRecursiveLock for Fold 3 as well, if I were to not use GCD, right? This is more for my knowledge base, so that I have my concepts clear. Additionally, thanks for your side note on Fold 3. I agree with you on the fact that it's be best to have a class retained, and open and close the connection as and when needed. I just rewrote some code that did multiple instantiations - what a nightmare that was. >_< I had put it in the question to give a better picture. :) – Declare

Perfect! Thanks a ton again! :D myKnowledge++ I've been planning to start using GCD in all our new projects, and the links you've provided are a great starting point! :) – Declare

+1 for GCD and Serial Queue.One good way of avoiding problems – Supernaturalism

In a variation of fold 2, you can use reader-writer pattern (concurrent queue, read with dispatch_sync, write with dispatch_barrier_async) as discussed in WWDC 2012 video - Asynchronous Design Patterns. – Tammeratammi

well with GCD next task just will wait until the second will finish, but what if I don't want next task to run at all if first task is running? I want to run next task only if nothing is running, but that poor GCD doesn't have methods like isRunning or isExecuting and we don't know if GCD task is still executing – Velvavelvet

Answer 2

As in Swift 3 in WWDC 2016 Session Session 720 Concurrent Programming With GCD in Swift 3, you should use queue

class MyObject {
  private let internalState: Int
  private let internalQueue: DispatchQueue

  var state: Int {
    get {
      return internalQueue.sync { internalState }
    }

    set (newValue) {
      internalQueue.sync { internalState = newValue }
    }
  }
}

Biotechnology

Answer 3

Subclass NSMutableArray to provide locking for the accessor (read and write) methods. Something like:

@interface MySafeMutableArray : NSMutableArray { NSRecursiveLock *lock; } @end

@implementation MySafeMutableArray

- (void)addObject:(id)obj {
  [self.lock lock];
  [super addObject: obj];
  [self.lock unlock];
}

// ...
@end

This approach encapsulates the locking as part of the array. Users don't need to change their calls (but may need to be aware that they could block/wait for access if the access is time critical). A significant advantage to this approach is that if you decide that you prefer not to use locks you can re-implement MySafeMutableArray to use dispatch queues - or whatever is best for your specific problem. For example, you could implement addObject as:

- (void)addObject:(id)obj {
    dispatch_sync (self.queue, ^{ [super addObject: obj] });
}

Note: if using locks, you'll surely need NSRecursiveLock, not NSLock, because you don't know of the Objective-C implementations of addObject, etc are themselves recursive.

Algonkian

Thanks for your reply. This is a good idea if I were to make a thread safe subclass of an object. :) – Declare

If you are leaving thread safety up to the callers (that is, you are not making a thread safe subclass, how ever implemented) then you will, repeat will, be setting yourself up for problems. You'd serve yourself to learn a bit about Spin technology. Good luck. – Algonkian

Any subclass of NSArray needs to implement several other methods as well; this is not a good example. – Acnode

@ilyan. Your comment isn't a good one either if you don't give any details that corroborate your claim. Could you be more specific? – Animal

You should never subclass any NS collections! Apple caution against it. It is better to make a category or use composition instead of subclassing. – Reynold