aspose file tools*
The moose likes Threads and Synchronization and the fly likes From SCJP6 of Kathy Sierra and Bert Bates Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "From SCJP6 of Kathy Sierra and Bert Bates" Watch "From SCJP6 of Kathy Sierra and Bert Bates" New topic
Author

From SCJP6 of Kathy Sierra and Bert Bates

Nick Widelec
Ranch Hand

Joined: Feb 28, 2013
Posts: 226

Here is a small quote about multi-threading programming.

The thread scheduler can decide to move the current thread from running to runnable in order to give another thread a chance to run. No reason is needed—the thread scheduler can trade threads in and out whenever it likes.

What does it actually mean? The thread scheduler is governed by a random algorithm?

Thanks in advance.


OCAJP 7, OCPJP 7
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

No, it doesn't mean it's governed by a random algorithm, although that is certainly allowed.

It's just saying that each thread scheduler is allowed to make its own rules about when to give threads CPU and how much time to give them, and we can't predict or control it.

Even if every scheduler used the simplest form of a round-robin time-sliced algorithm, it would still vary from one implementation to another because they'd be tuned to an appropriate number of cycles for the given architecture. And that doesn't even take into account how interrupts are dealt with.

A few different scheduling algorithms are discussed here, along with some overviews of what various OSes use.

So the point is: Don't make assumptions about when your thread will run or how much time it will get. And don't write code that relies on knowing or controlling those parameters.
Ranjith Kumar Reddy G
Greenhorn

Joined: Jun 01, 2013
Posts: 2
Multithreading / multiprogramming gives the illusion that multiple programs are executing at the same time. But this cannot be true in reality on a computer with a single processor. A processor at any given time can execute only a single program. To give user the illusion that multiple programs are running at the same time, a part of each program is executed in a round robin fashion.

Now, at any point time, there can be more than a single thread executing. A thread cannot be allowed to execute as long as it wants as this will give the impression that other programs are not executing / have become non responsive. So, the thread is given a time slice for executing its code. It is possible that at the end of this time slice, the thread has not yet finished execution. In this case, the thread is changed from running state to runnable state.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Ranjith Kumar Reddy G wrote:Multithreading / multiprogramming gives the illusion that multiple programs are executing at the same time. But this cannot be true in reality on a computer with a single processor.


Most computers these days have multiple CPUs and/or multiple cores per CPU. Even my phone has dual cores.

To give user the illusion that multiple programs are running at the same time, a part of each program is executed in a round robin fashion.


Round robin is one possible scheduling approach. but it's unlikely that strict round robin is employed on its own. There will almost certainly be a more sophisticated scheduling algorithm than that, although it may be partly round robin. We don't know when we write our code which algorithm will be used, which is the point of the quote the OP is asking about. Your comments didn't address his question at all.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: From SCJP6 of Kathy Sierra and Bert Bates