I have read that each core can have two threads. So, if my application in prod uses three octa core servers, does that mean my application can only handle 48 concurrent requests? Or am I mixing two different things here?
Would appreciate any clarity here.
In Java, you can have as many threads as you like and you're not limited by how many CPU cores you have. I.e. Even if you only had one processor with a single core, you could still write a multi-threaded application.
The JVM will perform context switching - it will execute Thread 1 for some time, then Thread 2 for some time, then maybe Thread 1 again, and so on, switching between the threads. These switches between threads can occur after just a few milliseconds, so it can give the illusion that the threads are running in parallel.
On some applications, it is faster to just use a single thread - because this process of context switching just adds further expense.
I did actually write a small multi-threaded application the other day though. It had about 30 threads, and this was a use case where multithreading did make the app more efficient.
I had about 30 URLs that I needed to hit and retrieve some data from. If I did this in a single thread, there would be waiting time each time I made a request and waited for a response (thus, blocking the application). When multi-threading, other threads will have been able to run whilst this waiting went on.
I hope this makes sense. It'll be worth reading up on Java Context Switching for more info.
This is a good source on the topic: https://docs.oracle.com/javase/tutorial/essential/concurrency/index.html
Related
Tell me, please, is there a guarantee that one thread will perform one task and will not switch to another during the execution of the current one? (I.e. pseudo-parallelism). That is, until this task is completed, the thread will not be released. At the same time, the system has two cores.
Also interested in why Tomcat has 200 threads by default if we have 2 cores (and *2 => 4 threads). What's the difference? With 4 threads, it will not be possible to ensure optimal operation of more than 1000 users...?
You're mixing two contexts: One thread might well be interrupted any time - or just wait for I/O to complete. During this time, the CPU core might execute another thread (or totally different process).
From within the thread, you'll always be in the same context, no switching appears. Other than executions possibly taking more or less time, the thread itself does not notice that it's interrupted. A thread is an abstraction for developing software, so that you're decoupled from context switches on the CPU.
Possible interruptions also explain why Webservers typically allocate a lot more threads for simultaneous executions than a machine has cores.
My expectation is that a webserver's default settings do not quite provide optimal resource allocations, but for most intents and purposes are a reasonable default, from which you might want to divert based on the characteristics of your application. e.g. if you're doing heavy CPU work without any I/O, your optimal setting will differ from an application with heavy I/O and minor CPU usage.
So, for application development purposes: A thread will execute exactly one task - interruption doesn't matter as it's transparent to the executed code. You might want to measure and tune your system and set optimal values rather than the default - but most of the times the webserver's default values are a better starting point than the number of your CPU cores.
I just had a quick question on how processors and threads work. According to my current understanding, a core can only perform 1 process at a time. But we are able to produce a thread pool(lets say 30) with a larger number than the number of cores that we posses(lets say 4) and have them run concurrently. How is this possible if we are only have 4 cores? I am also able to run my 30 thread program on my local computer and also continue to perform other activities on my computer such as watch movies or browse the internet.
I have read somewhere that scheduling of threads occurs and that sort of gives the illusion that these 30 threads are running concurrently by the 4 cores. Is this true and if so can someone explain how this works and also recommend some good reading on this?
Thank you in advance for the help.
Processes vs Threads
In days of old, each process had precisely one thread of execution, so processes were scheduled onto cores directly (and in these old days, there was almost only one core to schedule onto). However, in operating systems that support threading (which is almost all moderns OS's), it is threads, not processes that are scheduled. So for the rest of this discussion we will talk exclusively about threads, and you should understand that each running process has one or more threads of execution.
Parallelism vs Concurrency
When two threads are running in parallel, they are both running at the same time. For example, if we have two threads, A and B, then their parallel execution would look like this:
CPU 1: A ------------------------->
CPU 2: B ------------------------->
When two threads are running concurrently, their execution overlaps. Overlapping can happen in one of two ways: either the threads are executing at the same time (i.e. in parallel, as above), or their executions are being interleaved on the processor, like so:
CPU 1: A -----------> B ----------> A -----------> B ---------->
So, for our purposes, parallelism can be thought of as a special case of concurrency*
Scheduling
But we are able to produce a thread pool(lets say 30) with a larger number than the number of cores that we posses(lets say 4) and have them run concurrently. How is this possible if we are only have 4 cores?
In this case, they can run concurrently because the CPU scheduler is giving each one of those 30 threads some share of CPU time. Some threads will be running in parallel (if you have 4 cores, then 4 threads will be running in parallel at any one time), but all 30 threads will be running concurrently. The reason you can then go play games or browse the web is that these new threads are added to the thread pool/queue and also given a share of CPU time.
Logical vs Physical Cores
According to my current understanding, a core can only perform 1 process at a time
This is not quite true. Due to very clever hardware design and pipelining that would be much too long to go into here (plus I don't understand it), it is possible for one physical core to actually be executing two completely different threads of execution at the same time. Chew over that sentence a bit if you need to -- it still blows my mind.
This amazing feat is called simultaneous multi-threading (or popularly Hyper-Threading, although that is a proprietary name for a specific instance of such technology). Thus, we have physical cores, which are the actual hardware CPU cores, and logical cores, which is the number of cores the operating system tells software is available for use. Logical cores are essentially an abstraction. In typical modern Intel CPUs, each physical core acts as two logical cores.
can someone explain how this works and also recommend some good reading on this?
I would recommend Operating System Concepts if you really want to understand how processes, threads, and scheduling all work together.
The precise meanings of the terms parallel and concurrent are hotly debated, even here in our very own stack overflow. What one means by these terms depends a lot on the application domain.
Java do not perform Thread scheduling, it leaves this on Operating System to perform Thread scheduling.
For computationally intensive tasks, It is recommended to have thread pool size equal to number of cores available. But for I/O bound tasks we should have larger number of threads. There are many other variations, if both type of tasks are available and needs CPU time slice.
a core can only perform 1 process at a time
Yes, but they can multitask and create an illusion that they are processing more than one process at a time
How is this possible if we are only have 4 cores? I am also able to
run my 30 thread program on my local computer and also continue to
perform other activities on my computer
This is possible due to multitasking (which is concurrency). Lets say you started 30 threads and OS is also running 50 threads, all 80 threads will share 4 CPU cores by getting CPU time slice one by one (one thread per core at a time). Which means on average each core will run 80/4=20 threads concurrently. And you will feel all threads/processes are running at the same time.
can someone explain how this works
All of this happens at OS level. If you are a programmer then you should not worry about this. But if you are a student of OS then pick any OS book & learn more about Multi-threading at OS level in detail or find some good research paper for depth. One thing you should know that each OS handle these things in different way (but generally concepts are same)
There are some languages like Erlang, which use green threads (or processes), due to which they get the ability to map and schedule threads on their own eliminating OS. So, do some research on green threads as well if you are interested.
Note: You can also research on actors which is another abstraction over threads. Languages like Erlang, Scala etc use actors to accomplish tasks. One thread can have hundred of actors; each actor can perform different task (similar to threads in java).
This is a very vast and active research topic and there are many things to learn.
In short, your understanding of a core is correct. A core can execute 1 thread (aka process) at a time.
However, your program doesn't really run 30 threads at once. Of those 30 threads, only 4 are running at a time, and the other 26 are waiting. The CPU will schedule threads and give each thread a slice of time to run on a core. So the CPU will make all the threads take turns running.
A common misconception:
Having more threads will make my program run faster.
FALSE: Having more threads will NOT always make your program run faster. It just means the CPU has to do more switching, and in fact, having too many threads will make your program run slower because of the overhead caused by switching out all the different processes.
I have a general question:
my program will just go on processing something which does not require user input or system resources (like printer etc..) meaning, my program will not wait for any resources except CPU time.
The same program (let us say job) may be initiated by multiple users.
in this case, is it worth full to run this in a thread (meaning each user will get a feeling that his job is executed without delay.
or is it better to run the jobs sequentially?
The issue with running as separate threads is that, too many threads running simultaneously forcing the CPU utilization go over 100%.
Please suggest. Assume that user donot see his job progress. User is not worried when his job is finished. But at the same time, I want to have the CPU busy running the jobs.
If you don't care how long a process takes, or the length of time it takes is acceptable, then using one thread is likely to be the simplest solution. For example, many GUI applications only use one event handling thread.
If you want to keep all your CPUs busy you can start a number of busy loops to max out all the CPUs.
What you usually want is to reduce latency, or improve threadput by using more CPUs. Unless this is a goal, using more CPUs won't help you.
If the thread is genuinely purely CPU-bound, then it doesn't make sense to create more threads than there are cores (or virtual cores) available to process them. So on a quad-core machine, create no more than four threads (and probably only three, as your process isn't the only thing going on on the machine). On a quad-core machine with hyper-threading (two virtual threads per core), you might create six or seven. Creating too many additional threads (say, hundreds) causes unnecessary context-switching, which can be expensive if you really overdo it.
The converse is that on a multi-core machine, a single thread can only run on one core. So on a quad-core machine, running the jobs sequentially on a single thread will only utilize 25% of the CPU capacity.
So: Run the jobs in parallel up to the number of available cores, and sequentially (on each core) beyond that.
Big caveat: Your mileage may vary. There are lots of inputs to this equation, including what else is going on on the machine, and particularly whether the jobs really are CPU-bound (as opposed to system-bound, e.g., CPU and I/O subsystem and such).
I guess your program needs memory access. Memory access may be slow, and you really want to run the processor at that time. A common solution to limit the number of threads running at the same time is to use a thread pool.
in this case, is it worth full to run this in a thread (meaning each user will get a feeling that his job is executed without delay. or is it better to run the jobs sequentially?
It depends highly on the job. If it is interactive then running it immediately would give a better interface to the user. If the speed of the response is not an issue then maybe you don't want to incur the complexity costs of writing a multi-threaded program.
The issue with running as separate threads is that, too many threads running simultaneously forcing the CPU utilization go over 100%.
I wouldn't worry about this. One of the reasons why we use multiple threads is that we can make use of multiple processors to actually get the job done faster. In this case, depending on the OS, you can actually see more than 100% load for the process if you are using more than a full CPU -- this is expected. Also, if the CPU goes over 100%, the operating system will handle it fine unless you are worried that your application will be taking cycles away from a more important application.
I'm working on a multi-user Java webapp, where it is possible for clients to use the webapp API to do potentially naughty things, by passing code which will execute on our server in a sandbox.
For example, it is possible for a client to write a tight while(true) loop that impacts the performance of other clients.
Can you guys think of ways to limit the damage caused by these sorts of behaviors to other clients' performance?
We are using Glassfish for our application server.
The halting problem show that there is no way that a computer can reliably identify code that will not terminate.
The only way to do this reliably is to execute your code in a separate JVM which you then ask the operating system to shut down when it times out. A JVM not timing out can process more tasks so you can just reuse it.
One more idea would be byte-code instrumentation. Before you load the code sent by your client, manipulate it so it adds a short sleep in every loop and for every method call (or method entry).
This avoids clients clogging a whole CPU until they are done. Of course, they still block a Thread object (which takes some memory), and the slowing down is for every client, not only the malicious ones. Maybe make the first some tries free, then scale the waiting time up with each try (and set it down again if the thread has to wait for other reasons).
Modern day app servers use Thread Pooling for better performance. The problem is that one bad apple can spoil the bunch. What you need is an app server with one thread or maybe process per request. Of course there are going to be trade offs. but the OS will handle making sure that processing time gets allocated evenly.
NOTE: After researching a little more what you need is an engine that will create another process per request. If not a user can either cripple you servlet engine by having servlets with infinite loops and then posting multiple requests. Or he could simply do a System.exit in his code and bring everybody down.
You could use a parent thread to launch each request in a separate thread as suggested already, but then monitor the CPU time used by the threads using the ThreadMXBean class. You could then have the parent thread kill any threads that are misbehaving. This is if, of course, you can establish some kind of reasonable criteria for how much CPU time a thread should or should not be using. Maybe the rule could be that a certain initial amount of time plus a certain additional amount per second of wall clock time is OK?
I would make these client request threads have lower priority than the thread responsible for monitoring them.
I have made an OS simulator for a project, for the next part I have to modify the simulator to include 4 CPUs in place of only 1 CPU from the previous part, so that all the processes get done in a faster time.
So I have to add concurrency but I am not sure what the right design pattern is for this kind of thing. I need to know if the following will actually give me a speed up.
CPU extends Thread
//in main
get process1
get process 2
get process 3
get process 4
cpu1.run(process1)
cpu2.run(process2)
cpu3.run(process3)
cpu4.run(process4)
am I right in assuming that because cpus are extending thread they will all run concurrently for finish the 4 processes or will it be just like running the 4 processes on a single CPU?
By the nature of the question, this is a class project and that your representation of a cpu is relatively simple. For example, just runs a series of instructions like thread class. If however, you are trying to emulate real world CPUs and microprocessors, we need to know more about the cpu features: scheduling, event handling and other low level aspects that are normally hidden.
But, in the simple case, the answer is generally yes.
Note, depending on the tasks in those processes and the CPU you run this code on, you may see different behaviors because of how the CPU and JVM are actually implementing threads. But, I think in your case it isn't relevant.
It depends mainly on 3 things:
The kind of operations involved in threads. Do they share variables? Do they need synchronization between themselves or are they completely indipendent?
The environment in which they are executed. You inserted Java tag but it's not clear if you want to give your simulator the ability to schedule processes on multi (real) cpus or just use more than one core. By the way if you plan to use more real CPUs you have to avoid green threads (wikipedia).
If you want to use multiple real cores you have to care about the structure of the CPU too. Which kind of cache do they share? And so on..
Do you have anykind of simulated scheduler inside your OS?
Time slicing says that you will have to divide the single CPU among the N threads that you decide to start. There won't be any parallelism.
In you example each CPU is able to run a process concurrently, so if you just have 4 processes you're doing good.
If you want your program to work also for the case where there are more processes than CPUs you need something more complex. In that case I would recommend you take a look at the Java concurrency framework.
For the simplest solution when you have more than 4 processes that you want to run I would use ExecutorService.newFixedThreadPool(4), and add each process (as a Callable) to the resulting thread-pool using either invokeAll() or submit().
BUT this does not give you concurrency between all running processes (it will only pick up the 5th process when one of the first 4 processes has completed). If you want your program to act as a real multi-threaded OS (where more processes can be active than CPUs available) you'll have to add some sort of scheduler that can assign a part of a process on one of the available CPUs, then (before the first is done) let another process use that same CPU for a part of its work, etc.. So it will have to allow for part of processes to be done, then do part of one or more other processes then let the first do a bit more of its work, etc until all processes are done.
Your simulator then also needs some way to decide when a process can be 'paused' (i.e. put aside by the scheduler to be picked up later)...