1

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.

Mea
  • 17
  • 3
  • Are you in school? This is part of a "system specialty" in the com sci major. Basically you learn about computers as a "whole system," how the operating system works and how it time slices and stuff. And also common algorithms used by OSs for doing its job, including time slicing programs/threads. – markspace Nov 24 '18 at 02:51
  • Example: https://cs.stanford.edu/academics/current-masters/choosing-specialization#systems Even if you don't want to do those things, understanding how they work can let you do your job better and easier, because everybody has to deal with systems even if you don't work on them directly. Personally I'd recommend taking some classes in systems even if you want to specialize in something else. – markspace Nov 24 '18 at 02:53
  • `What amount of time a thread has before CPU is given to other threads?` You can look for information on specific subjects just by doing a web search. For example, "linux timeslice": https://stackoverflow.com/questions/16401294/how-to-know-linux-scheduler-time-slice It looks like it's 100 milliseconds. – markspace Nov 24 '18 at 03:08
  • A web search for "unix internals" or "linux internals" will also get you books and papers on how an OS is put together. – markspace Nov 24 '18 at 03:13
  • @markspace I am currently learning java in school and just got introduced to multi-threading. These were just the questions that I was curious about. – Mea Nov 24 '18 at 06:49

2 Answers2

0

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

Guilherme Henrique Santos Sous
  • 16
  • 1
  • Threads share heap space, but not stack space. The distinction can be (often is) important. – markspace Nov 24 '18 at 02:49
  • They share stack space too. They follow an agreement that ensures that they don't use the stack of another thread but the OS doesn't prevent it, because all threads in a process share the same memory space. (In Java, without native code or the Unsafe class, you can't mess up another rhread's stack) – Erwin Bolwidt Nov 24 '18 at 03:13
0

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.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
  • So in my example, if t1 is still sleeping then it can't get scheduled, meaning CPU time is given to t3 again unless it isn't still sleeping? – Mea Nov 24 '18 at 06:53
  • @Mea Correct. A thread that's not ready-to-run cannot be scheduled until something makes it ready-to-run. – David Schwartz Nov 24 '18 at 18:49