Why is NSLock necessary to ensure thread-safety?

[tonyxiao]

This is more of a general question rather than a specific issue, but I was wondering, why is NSLock necessary to make sure SPSearchStore is thread-safe? SPSearchStore seems to use NSOperationQueue quite extensively, which has serial queues that are both more efficient than locks and achieve the same effect. Thoughts?

[phildow]

Good point. Looking at the code, I recall my original reason for employing locks, and I wonder if they remain necessary.

The project from which I factored the code did not originally employ the operation queue, so locks were an essential part of maintaining the index's integrity. According to the docs, you may read from and write to an index simultaneously, but only one operation of each at a time.

With the serial operation que, you're right, the writing lock shouldn't be necessary. However, I notice that the code doesn't queue every write operation. In a number of cases a public api goes straight to the private method which employs the lock but not the queue. Some of the public apis also access the index directly and so lock around their implementation, for example the setProperties:forDocument method.

I believe the code could be re-written to remove the write lock and use only the operation queue, but in it's current form I believe it's necessary to maintain the locks.

Along a similar line, I believe it should be possible to add a second NSOperationQueue for read operations, and always use the queue instead of the read lock.

[tonyxiao]

Thanks for clarifying! Got it, I'll try to update the code to use queues if I get a chance.