How does one create a thread safe singleton object in objective-c. for eg. If I have a shared data controller which is a singleton object what will happen if two or more threads are accessing it at the same time..? Or these objects have thread safety by default..?
update:
Is it under this scenario that the objects inside the datacontroller’s property decide if it is thread safe or not.. ? Like my datacontroller has NSMutableArray and it is set nonatomic it will not be thread safe. What will happen to its value in that case?
update:2
And what actually does @synchronized(self) do..?
If the data controller is not threadsafe, then undefined behavior could happen — avoid it at all costs =)
NSObjects are definitely not threadsafe by default. Using atomic properties does not make a class threadsafe (added that because it’s a popular misconception).
The typical solution would involve making sure that all of your mutable state is protected with appropriate locking (e.g. a mutex or
@synchronized).When I say mutable state, I am referring to an object which can mutate externally or internally. If you are not sure, lock to be sure the types are read or written from multiple threads. This must happen at reading and writing – always. If you have a lot of reading, a readwrite lock may be a better, more specialized lock.
To answer in more detail, you’d have to post some code.
Update
Think of it as being transitive. Your NSMutableArray, the objects it holds, and all external references to them must be used in a threadsafe manner, and you have to track all that. Typically, you start by reducing what mutable state you share. Instead of giving clients a reference to the array, give them copies of the elements held by the array. Meanwhile, protect all reads, writes, and element copying with a lock.
For simplicity, I will demonstrate using
@synchronize:Update 2
@synchronizedsets up an object level lock. You can think of it as a recursive (or reentrant) lock exclusive to your instance. It’s also quite slow compared to other locking approaches. The code above uses it, and it is threadsafe and equivalent to holding a recursive lock, and locking and unlocking at the@synchronizedboundaries.