I know that you shouldn't have an exaggerated number of threads because the hardware crashes, it's not that big of a deal. But when I saw these images, a doubt arose...
Why does splitting processes take less time? Could it be that this way I use more cores instead of one and not just one to run the main thread?
Am I right or am I wrong?
From the title:
The idea of threads is to have work done at the same time. An example for this is: imagine that you have to paint a room with four walls. If you only have a painter who paints 1 wall in 1 hour, it will take 4 hours to paint the room. If you need to speed up this work, you hire one more painter and the room will be painted in 2 hours, but you will have to pay the painter extra. The same thing happens with threads: you can get more speed but you will pay an extra price to get that speed, in this case it is paying the extra processing to have two (or more) processes running at the same time. For current times with computers and devices with at least two cores in the microprocessor, this is not so much of a problem. But keep in mind that there are processes that cannot be optimized using threads.
From the text:
From the above answer, it depends on the type of process. There are things that cannot be optimized with threads, for example disk access or access through the network, those are slow processes. However, there are processes that can be optimized using threads, such as the generation of invoices for a group of clients: you can have a method
generaFactura(long idCliente)
, have a pool of threads and send tasks to the pool so that the generation of invoices is in parallel (similar to painting the walls of a room).This in code would be represented as follows, using
ExecutorService
(because it is better to use a framework that manages threads instead of having to manage them manually):In the case of Java, this depends. When you open a thread, what Java does is delegate the operation to the operating system. So the use of one or more cores in this case will depend on the operating system and not on Java. This means that your application written in Java using N threads on Linux may perform better (or perhaps worse) than running it on Windows. Also, the execution of the threads is associated with the hardware as you mentioned. Therefore, even if you have the same operating system eg CentOS 6.5 (a linux distribution) it can perform differently between computers due to the hardware they have: number of cores, cache, ram, etc.
As shown in the code example above, the number of threads to use should depend on benchmarking the task being performed and choosing which would be the best value considering the environment or environments to be executed. There is no perfect formula or calculation for it.
In addition to this, you can open one or more threads within other threads. An example of this is when you create a web application. Every request made to the server is done within a thread, and if within the request process you open a thread, then you are opening a thread within another thread. This is not a problem, it is fully supported by current operating systems.
In short: only use threads if you really need to. And always remember to benchmark your process before using threads and after using threads so you can assess if the cost paid for the use of threads is worth the time gained.
Of course you are right. Broadly speaking, it will obviously take longer if your processes are executed sequentially than if they are all executed in parallel (Concurrency). If they are done in parallel, your system would have more efficiency when running.
I comment on this assuming that your processes are candidates to be executed in a thread, such as an asynchronous task, you must be careful because there are processes or tasks that could cause problems when executed in Threads.
Exactly when executing more tasks these are distributed (depending on the hardware and the OS) for processing in the cores.
There are some properties of the threads that it would be interesting to review:
synchronized
, only the calling thread has access to the Object instance, any other thread trying to access this same instance will have to wait.ThreadGroup
, implements thread pools in Java.