Question

Use case:

1. There is a lot of requests that should be processed.
2. The time taken to process each request varies.
3. Request are meant to be processed concurrently (now they are pushed into the global queue got by dispatch_get_global_queue).
4. Requests coming from the same client preferably should be processed synchronously, e.g., processing of rca1 from ca should be finished before start processing rca2, at the same time rcb1, rcd3, etc, are being processed.
   
   rca i : requests from client a.
5. If processing a request is taking too long, i.e., more than TIME_OUT, other requests from the same client can start processing.

Using dispatch_get_global_queue and a serial queuevoid dispatch_after(
dispatch_time_t when,
dispatch_queue_t queue,
dispatch_block_t block) for each client would be suboptimal when rca1 processing is finished but when has not arrived yet.

Having a serial queue per customer wouldn’t satisfy 5.

---

I’m aware that GCD is based on a different paradigm but is there any equivalent of pthread_mutex_timedlock or lockBeforeDate or Lock.tryLock in GCD?

How to implement the functionality provided by timed locks using GCD?

Grand Central Dispatch (GCD) Reference

Answer 1

You could have the next job block on a dispatch_semaphore with a timeout. You’d need to wait on job submission, though, not just job execution… otherwise GCD will spin up a ton of threads that immediately wait, which is not what you want.