I know that the max number of threads spawned cannot exceed 66 through the response to this question. But is there a way to limit the thread count to a value which an user has defined?
Asked
Active
Viewed 1,554 times
2
-
What is the ultimate goal? – Hexfire Jan 23 '18 at 07:13
-
The goal is to restrict the number of threads to a user specified value, **n** <64 – Anmol Chugh Jan 23 '18 at 07:34
-
The question is why you would need that and what benefits do you find in that kind of restriction. As explained in the question you have [referred](https://stackoverflow.com/questions/7213845/number-of-threads-created-by-gcd), GCD is ultimately not magic, and introducing that kind of restriction without good application design makes no sense. And vice versa, if application is designed well and GCD is handled on design-level, artificial restrictions don't make any sense, nor benefits on performance. – Hexfire Jan 23 '18 at 07:44
-
Further to @Hexfire's comment, GCD provides an abstraction on top of threads, so you typically don't think of threads when you are using GCD. You decide whether your operations must run serially or can run concurrently and queue them to an appropriate queue for dispatch. – Paulw11 Jan 23 '18 at 07:50
-
I asked this question keeping a scenario in mind where multiple applications are spawning their respective threads. In that case I wanted to know if it is possible to restrict the number of threads that my application can spawn in order to prevent all the resources from being hogged by my application alone. – Anmol Chugh Jan 23 '18 at 08:43
-
Here's an example why I'd want this: I calculate icon previews of files (macOS) in a concurrent queue. If I queue too many such tasks, I'll run into the >64 thread limit and the app deadlocks. Since this preview process is a known factor of increasing threads in my code, and I should be able to tell the particular queue I created to not raise more than, say, 32 concurrent threads. That way I'd stay on the safe side as I know I won't spawn >32 threads anywhere else in my app. – Thomas Tempelmann Oct 31 '19 at 14:09
-
To add to my previous comment: What seems wrong to me is that GCD even lets this happen - I have only 4 other threads in my app, yet it will happily create > 60 threads for this single queue, disregarding the system's 64 thread limit. Shouldn't that be regarded a bug? Oddly, though, I see this deadlock in macOS 10.15.1 but not in 10.13.6 – Thomas Tempelmann Oct 31 '19 at 14:11
1 Answers
1
From my experience and work with GCD under various circumstances, I believe this is not possible.
Said that, it is very important to understand, that by using GCD, you spawn queues, not threads. Whenever a call to create a queue is made from your code, GCD subsystem in its turn checks OS condition and seeks for available resources. New threads are then created under the hood based on these conditions – in the order and with the resources allocated, not controlled by you. This is clearly explained in official documentation:
When it comes to adding concurrency to an application, dispatch queues provide several advantages over threads. The most direct advantage is the simplicity of the work-queue programming model. With threads, you have to write code both for the work you want to perform and for the creation and management of the threads themselves. Dispatch queues let you focus on the work you actually want to perform without having to worry about the thread creation and management. Instead, the system handles all of the thread creation and management for you. The advantage is that the system is able to manage threads much more efficiently than any single application ever could. The system can scale the number of threads dynamically based on the available resources and current system conditions. In addition, the system is usually able to start running your task more quickly than you could if you created the thread yourself.
Source: Dispatch Queues
There is no way you can control resources consumption with GCD, like by setting some kind of threshold. GCD is a high-level abstraction over low-level things, such as threads, and it manages it for you.
The only way you can possibly influence how many resources particular task within your application should take, is by setting its QoS (Quality of Service) class (formerly known simply as priority, extended to a more complex concept). To be brief, you can classify tasks within your application based on their importance, this way helping GCD and your application be more resource- and battery- efficient. Its employment is highly encouraged in complex applications with vast concurrency usage. Even still, however, this kind of regulation from developer end has its limits and ultimately does not address the goal to control threads creation:
Apps and operations compete to use finite resources—CPU, memory, network interfaces, and so on. In order to remain responsive and efficient, the system needs to prioritize tasks and make intelligent decisions about when to execute them.
Work that directly impacts the user, such as UI updates, is extremely important and takes precedence over other work that may be occurring in the background. This higher priority work often uses more energy, as it may require substantial and immediate access to system resources.
As a developer, you can help the system prioritize more effectively by categorizing your app’s work, based on importance. Even if you’ve implemented other efficiency measures, such as deferring work until an optimal time, the system still needs to perform some level of prioritization. Therefore, it is still important to categorize the work your app performs.
To conclude, if you are deliberate in your intent to control threads, don't use GCD. Use low-level programming techniques and manage them yourself. If you use GCD, then you agree to leave this kind of responsibility to GCD.
Hexfire
- 5,945
- 8
- 32
- 42