What are Dispatch workloops?

Question

Created Dec ’24

Replies 2

Boosts 0

Participants 2

I’ve been experimenting with Dispatch, and workloops in particular. I gather that they’re similar to serial queues, except that they reorder work items by QoS. I suspect there’s more to workloops than meets the eye, though; calling dispatch_set_target_queue on them has no effect, in spite of the <dispatch/workloop.h> saying that workloops “can be passed to all APIs accepting a dispatch queue, except for functions from the dispatch_sync() family”.

Workloops keep showing up in odd places like Metal and Network.framework backtraces, and <dispatch/workloop.h> includes functionality for tying workloops to os_workgroups (?!).

What exactly is a workloop beyond just a serial queue with priority ordering, and why can’t I set the target queue of one?

Boost

Answer 1

DTS Engineer OP

Apple

Dec ’24

Accepted Answer

Recommended

What exactly is a workloop beyond just a serial queue with priority ordering

That’s about it.

why can’t I set the target queue of one?

Because the workloop is intended to be the target, not the source, of work. The idea is to have one workloop per subsystem and then have various serial queue, or serial queue hierarchies, target that. This keeps everything serialised while allowing higher-priority work items to jump ahead of lower-priority ones.

Honestly, if you could set a target queue I’m not sure how that’d even work. If you set a workloop’s target queue to a serial queue, you’d be back in FIFO Land™.

If you haven’t already watching it, the WWDC 2017 session on Dispatch is really good value. There’s a link to it from the Concurrency Resources post.

ps I love your blog! [1]

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] For those reading along at home, that’s:

https://blog.xoria.org

1

Answer 2

lunarazzaghipour OP

Dec ’24

That’s about it.

I have to admit that I’m mildly disappointed! I’d kind of convinced myself that workloops must be some sort of dark magic.

Because the workloop is intended to be the target, not the source, of work. The idea is to have one workloop per subsystem and then have various serial queue, or serial queue hierarchies, target that.

This makes sense, thank you! I can see how workloops map well onto the ideas presented in the WWDC session you linked. Keep using serial queues where ordering matters, otherwise target everything at one workloop (instead of a serial queue) per subsystem.

Honestly, if you could set a target queue I’m not sure how that’d even work. If you set a workloop’s target queue to a serial queue, you’d be back in FIFO Land™.

I was imagining that targeting a workloop at a serial queue would interleave the workloop’s work items (which are still ordered by priority) with the serial queue’s other work items (which maintain their ordering); it’s as if you’d targeted one serial queue at another, except that the first queue happens to have had its work submitted in descending priority order. Targeting a workloop at another workloop would function in the same way as how targeting a serial queue at a workloop does today, minus the ordering requirement.

I suppose the purpose of this would be the same as why we target serial queues at one another: to apply labels for debugging and to assign QoS classes. Of course, none of this matters since I’m just imagining things.

ps I love your blog!

Thank you for the compliment and for the fantastic answers!

0