Hi guys.
I've been trying to find some info on what a maximum number of threads that IOS can create is.
Yes, there are different devices as well as processors, in addiction GPU creates threads as well.
Perhaps, somebody can give an approximate answer.
Thanks for your time.
Take care.
As with any operating system that runs more than one process the number of actual active threads cannot be determined for a single process since another process may be doing heavy work loads using many threads while the process in question is running. Idle threads are limited just by allocation of memory. The usual question like this is about maximum queue width or maximum parallelism of an API, more often than not that is not really an answerable. Perhaps it is better to ask what exactly do you need that information for?
If for example you are asking for a suggested maximumConcurrentOperations per hardware: then there are two good answers 1 or max, dispatch talks directly to the kernel about scheduled work and it is the kernel that decides which threads out of the pool it will schedule to run. So instead it is more of an apropos question to ask; how intense should each operation be? In that case it is often a good rule of thumb that they should be measurable work loads in milliseconds of computational load or more. Anything less and perhaps using locks is a better use of cpu overhead (because context switches do have a cost).
2 Likes
Thanks for the answer. I meant to say: " What is the maximum number of threads that IOS can create in one clock time". I don't need the info for some particular purpose, I was just wondering.
There's a paragraph named " Avoiding Excessive Thread Creation " in ADD that contains the sentence,
If too many tasks block, the system may run out of threads for your app.
Therefore, I came to conclusion that there must be some limitation.
So that is a limitation posed by the internals of the kernel. Creating a thread (or a queue with a dedicated thread backing it) will consume kernel resources to do so. If threads get blocked (and not being allowed to be parked as a relinquished resource) the kernel will run out of space to allocate to the process. There are technical limits but in practice I have seen processes with dozens of threads running just fine. If you try to spawn a thread for every asynchronous item to execute then it is going to go quite poorly, but if that spawn is by libdispatch's communication with the kernel then you can have more queues than say threads, however even that resource is also limited. Queue re-use or sharing is ideal to break them up instead of by task but by kind of work. For example if you do I/O then it is sensible to have a queue dedicated for I/O, likewise a queue for processing items etc. But where it breaks down is using queues as locks; that may have been vogue in the past but in reality it doesn't turn out well in practice.
Isolate by job kind if you can, don't use a queue for VERY short things, and favor queues over threads (or better yet use Swift concurrency) and if you have a reasonable limit of a handful of queues in your app then that excess won't be an issue. So you can see this in the debugger: 10 threads for an app isn't a whole lot, 60 some odd... that is excessive, 100 please rethink the design.
There are some really great talks from the libdispatch team on the developer.apple.com site to go into considerably more depth and expertise about it; Swift concurrency: Behind the scenes - WWDC21 - Videos - Apple Developer and any of the other videos she has done are fantastic resources in my opinion. Another from a bit ago that might be good reference: Modernizing Grand Central Dispatch Usage - WWDC17 - Videos - Apple Developer
4 Likes
Threads are not easy,I got you. Thanks for the resources, I'm going to watch it right away.