Ytukyg

I think I am overthinking the concept of threads in Java, and this might be a dumb question. I read some of the answered topics on threads, but they don't actually answer my question.

So suppose we have 3 threads: t1, t2, t3.

t1's run method:

thread.sleep(1000);

System.out.println("Hello");

t2's run method:

System.out.println("Hi");

t3's run method:

thread.sleep(3000);

System.out.println("Bye");

t1.start();

t2.start();

t3.start();

I understand that any of these threads could be scheduled first. But what actually goes inside the CPU? I've read in a book that each of these thread gets some CPU time and threads are switched inorder to create a illusion of parallel running. What amount of time a thread has before CPU is given to other threads?

Also, lets say t1 is scheduled first means it gets CPU time then it goes to sleep for 1000ms as in the above code. Now lets say t2 gets CPU time, and since it isn't sleeping, it prints 'Hi'. Now t3 gets cpu time, it sleeps for 3000ms therefore t1 gets the cpu time again. So now does t1 picks up from where it has left before? what if t1 is still sleeping because 1000ms hasn't passed since the last time?

I might be taking it in a wrong way, but I'm juggling through these concepts.

The threads are subdivisions of a process and share the same memory space.
The scheduler decides what thread goes to execution. And it is SO dependent.

You can find more info here: https://www.javamex.com/tutorials/threads/how_threads_work.shtml

I understand that any of these threads could be scheduled first. But what actually goes inside the CPU? I've read in a book that each of these thread gets some CPU time and threads are switched inorder to create a illusion of parallel running. What amount of time a thread has before CPU is given to other threads?

Most modern CPUs can run more than one thread at a time. If the CPU cannot actually run as many threads in parallel as threads that wish to run, the scheduler will make a decision of how long to let each thread run. Generally, it picks a time that is short enough to permit operation to feel smooth but not switch so often that the cost penalty of switching threads significantly impacts performance.

Also, lets say t1 is scheduled first means it gets CPU time then it goes to sleep for 1000ms as in the above code.

When a thread goes to sleep, it is no longer ready-to-run.

Now lets say t2 gets CPU time, and since it isn't sleeping, it prints 'Hi'. Now t3 gets cpu time, it sleeps for 3000ms therefore t1 gets the cpu time again. So now does t1 picks up from where it has left before? what if t1 is still sleeping because 1000ms hasn't passed since the last time?

If a thread is still sleeping, it is not ready-to-run and so it cannot get scheduled. A thread sleeps by arranging itself to be made ready-to-run at some future time and then setting itself not ready-to-run. Only threads that are ready-to-run can be scheduled. An exception might apply if the sleep is for a very short amount of time.

The scheduler arranges to schedule the threads that are ready-to-run, descheduling threads that are no longer ready-to-run and switching if a thread occupies the CPU for too long to give other threads a chance to run. Mechanisms exist to allow threads to wait for things (like disk I/O, network I/O, timeouts, other threads to give them work to do,and so on) by arranging to be made ready-to-run when something happens.