Question

I have some code like this:

doDatabaseFetch {
   ...
   @synchronized(self) {
      ...
   }
}

and many objects that call doDatabaseFetch as the user uses the view.

My problem is, I have an operation (navigate to the next view) that also requires a database fetch. My problem is that it hits the same synchronize block and waits it’s turn! I would ideally like this operation to kill all the threads waiting or give this thread a higher priority so that it can execute immediately.

Apple says that

The recommended way to exit a thread is to let it exit its entry point routine normally. Although Cocoa, POSIX, and Multiprocessing Services offer routines for killing threads directly, the use of such routines is strongly discouraged.

So I don’t think I should kill the threads… but how can I let them exit normally if they’re waiting on a synchronized block? Will I have to write my own semaphore to handle this behavior?

Thanks!
Nick.

Answer 1

The first question to ask here – do you need that big of a critical section so many threads are waiting to enter? What you are doing here is serializing parallel execution, i.e. making your program single-threaded again (but slower.) Reduce the lock scope as much as possible, think about reducing contention at the application level, use appropriate synchronization tools (wait/signal) – you’ll find that you don’t need to kill threads, pretty much ever. I know it’s a very general advise, but it really helps to think that way.