This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes OS context switch Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "OS context switch" Watch "OS context switch" New topic
Author

OS context switch

Jawahar Muthukrishnan
Greenhorn

Joined: Jan 07, 2004
Posts: 1
Scenario:
Assume a scenario where there are a large number of threads waiting for CPU time. The OS is serving a thread which has established a socket connection with a remote client. The remote client has started transferring a large file through the connection.
Question:
If the time required to transfer the file through the socket is longer than the context-switch time of the OS (pre-emptive scheduling) like Windows, will the OS do a context-switch??? If it does, what happens to the REMOTE client which is in the middle of transferring data??? Will there be any data loss??
Thanks
Jawahar
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
If the time required to transfer the file through the socket is longer than the context-switch time of the OS (pre-emptive scheduling) like Windows, will the OS do a context-switch???
Yes, probably. I suspct that even with preemtive scheduling, there's a certain atomicity of actions, and thread management can't or won't cut things off too abruptly. When a tread is pre-emted, it must be able to save its state well enough that it can resume later without ill effects (other than a slight delay).
If it does, what happens to the REMOTE client which is in the middle of transferring data??? Will there be any data loss??
There shouldn't be any data loss - this is fairly standard usage of threads, I have to assume either the OS or the JVM is designed to handle it, or they wouldn't be able to claim to have implemented a JVM on that OS. Since a JVM is required to bea able to implement threads according to the JLS and JVM specs, which don't allow for threads which just randomly drop data. The remote client may observe some pauses in transmission of data, but that's normal - the client doesn't know or care whether delays are caused by something on the server, or in the network. It just waits until it has recieved enough data to process, then it processes the data. Usually there's a loop where it waits for an EOF or other signal (depending what protocol you're using).


"I'm not back." - Bill Harding, Twister
 
GeeCON Prague 2014
 
subject: OS context switch