I have an NSMutableArray containing many objects.
What happens if a change is made to the array, while I am making a copy of the array using [NSMutableArray arrayWithArray:someArray];
Eg: If an object an object is removed from the array while the copy is being made?
I’m not sure how to test this scenario.
EDIT: The objects are not released (as they are retained elsewhere). I just use this array as a lookup table.
as you know, the container/collection is not guaranteed to be thread safe. what could happen if you change the array while copying or reading? a lot of things. the obvious cases are that it may be reallocating at the time, it may pass or return an invalid reference to you (e.g. the most recently removed), or it may access objects which have been released (from another thread). in addition to things that will make your app crash or cause other UB, it may not return correct or consistent values. it is a misinterpretation of the data. neither are good.
you don’t test the scenario – threading issues are difficult to reproduce and you really can never cover all the cases. since the object itself does not guaranteee thread safety – your implementation has to restrict accesses/mutations/interactions to one thread at a time. when dealing with object which are used in multithreaded contexts: anytime you access or query information from an object’s mutable state, you should guard the object (e.g. with a lock). therefore, you simply lock it while using it. lock/copy/unlock/use copy is also common. for an NSMutableArray, examples of mutable state would be all its objects and its count. its operations and mutations also use the object’s mutable state, so they are restricted.
if you only use this object from one thread, then obviously don’t need to lock it. this is also a reason why passing by copy and holding immutable variants are both good ideas in most cases. you don’t need a lock for each object, a guard for the object which holds it is often a good way to design a class for thread safety.
Update
if you have not properly guarded the collection, it’s as good as undefined behavior and you’re lucky if it crashes.
you need to take the appropriate precautions to avoid undefined behavior. your program is operating in that domain when it’s not properly guarded.
to elaborate: retaining the objects externally only reduces the probability of undefined behave\ior, but it certainly does not eliminate it. more examples of consequences include exceptions, segfaults, reading or writing memory which is used as another active allocation (which may show up as very mysterious issues which may also be virtually impossible to reproduce).
i encourage you to guard properly or take another approach. UB is EVIL 🙂