3 ms·
> Every other OS and languages have tried their own variant of the libdispatch and from what I have read they all failed to some extent. LibDispatch is Apple's
by Const-me 6y ago
> Every other OS and languages have tried their own variant of the libdispatch and from what I have read they all failed to some extent.
LibDispatch is Apple's re-implementation of SubmitThreadpoolWork WinAPI, introduced in Windows Vista 3 years before libdispatch. Thread pools work better in Windows because OS kernel support.
In libdispatch and similar cross-platform libraries, OS kernel is unaware of the thread pool. The kernel implements individual threads and schedules them fairly, the rest of the code is user mode.
Windows has I/O completion ports (IOCP) in the kernel since forever, more specifically since NT 3.5 shipped in 1994. That newer Vista API is probably built on top, or uses same kernel features.
Here's an important part from IOCP's documentation:
> The system also allows a thread waiting in GetQueuedCompletionStatus to process a completion packet if another running thread associated with the same I/O completion port enters a wait state for other reasons, for example the SuspendThread function.
This is the unique part which can't be implemented in a user mode library. If you create a thread pool with 1 OS thread per hardware thread, and call any blocking API from the pool, a hardware thread will go to sleep. If you create a thread pool with multiple OS threads per hardware thread, the OS will use all of them concurrently and you'll get overhead from context switches, also latency spikes.
The problem can only be solved in OS kernel. That's why in Windows, thread pools usually works OK.
- alblue 6y agoThere is very heavy integration between libdispatch and the kennel on macOS. In fact, when porting libdispatch to non macOS platforms for Swift on Linux, the developers were surprised that they couldn’t just unilaterally introduce changes into the Linux kernel in the same way that they had done on macOS itself. As a result on Linux platforms, the libdispatch libraries are a software bolt on that doesn’t have the same level of tight integration (and therefore performance) than on macOS. Given that libdispatch existed in macOS with kernel integration a long time before the Linux library port was added, your claim that it was cross platform doesn’t stand up. It was macOS first, with kernel integration, and then a separate compatibility layer afterwards for non-macOS platforms much later. Source: I helped out with the porting of Swift to Linux when at Apple.
- Const-me 6y agoInteresting. Can you confirm OSX has thread pool support in the kernel, in a way that affects thread scheduling in a non-trivial way? Or is that kernel support only for message passing, callbacks, memory management, synchronization, logging or similar?
- alblue 6y agoThe issue is that dispatch needs to know what’s running and to allow for the threads to effectively work with the thread schedule to service dispatch in an appropriate way. On macOS, the implementation is done in kernel, although there is a front end user library that used to interact with it. This article, although a few years old, talks about the separation of the parts and goes to explain why it’s not a trivial port to other operating systems. https://gigaom.com/2009/09/14/apple-open-sources-grand-central-dispatch/ https://gigaom.com/2009/09/14/apple-open-sources-grand-centr...