Sierra Bluetooth Problems Due to GCD?
One of the well-known problems in multi-tasking and concurrency is deadlock, when one task sits waiting for another, and the other task cannot proceed until the first task is complete. GCD is not immune from deadlock, and there are some curious issues which have arisen in El Capitan and Sierra which look suspiciously as if deadlock may have been their root cause.
I am also beginning to wonder if some of the persistent problems which we have experienced with Bluetooth disconnects, in both El Capitan and Sierra, are the result of issues within GCD, rather than in the Bluetooth drivers themselves. Even now, with Sierra 10.12.4, seldom a day passes without my Magic Trackpad 2 spontaneously disconnecting, then reconnecting.
These are all made the more complex by GCD’s heuristics, its ‘smart’ dispatching system. When trying to identify and diagnose problems, predictability is one of the most important properties, but because of those complex heuristics nothing about GCD follows clear and simple rules.
Previously: Sierra Bluetooth Problems and the Logitech K811 Keyboard.
Update (2017-05-15): Howard Oakley:
libdispatch(‘old’ GCD) provides facilities which include the management and dispatch of code threads or Operation Objects, which can be distributed optimally across the processor cores available in a Mac. In particular it manages multiple dispatch queues.Centralized Task Scheduling (CTS) allows a developer to assign criteria for when a task should be performed, so that scheduled and other tasks can be deferred when necessary, for example when a laptop is running from its battery rather than mains power.
I hope that I have shown that Duet Activity Scheduler (DAS) manages heuristically a pool or queue of tasks or activities, and determines when to dispatch them for execution.
2 Comments RSS · Twitter
GCD won't deadlock if you avoid *_sync (*_async is cool), and *_wait (*_notify is cool).
On the other hand it can livelock (although it's overhead actually goes down as you load it which makes it harder to livelock then other threading systems).
I do know that GCD seems like it would be harder to debug then straight posix threads, but the 100s of kernel bugs it uncovered while SnowLeopard was being written were actually uncovered because it is *more* predictable (and has much much lower latency) then normal posix threading.
