CODEWITHSUNDEEP
multithreading
Casto
Casto

Reputation: 305

C# When thread switching will most probably occur?

I was wondering when .Net would most probably switch from a thread to another? I understand we can't predict when this will happen exactly, but is there any intelligence in this? For example, when a thread is executed will it try to wait for a method to returns or a loop to finish before switching?

Upvotes: 0

Views: 85

Answers (3)

user6055072
user6055072

Reputation: 1

I read your question now, it may not be rellevant anymore, but after reading the above answers, i want to just to make sure:

Threads are managed (or as i know) by the process they belong to. There is nothing to do with the Operation System(and that's is the main reason why working with multithreads is more faster than working with multiprocess, because there are data sharing between threads and the switching between them is occuring faster than the context switch wich occure between process by the Short-Term-Scheduler). (NOTE: There are two types of threads: USER_MODE' threads and KERNEL_MODE' threadss, and each os can have both of them or just on of them. Anyway a thread that working in a user application environment is considered as a USER_MODE' thread and managed by the process it's belong to.)

Am I Write? Thanks!!!

Upvotes: 0

Martin James
Martin James

Reputation: 24887

Of course there is 'intelligence', of a sort:). The set of running threads can only change upon an interrupt, either:

An actual hardware interrupt from a peripheral device, eg. disk, NIC, KB, mouse, timer.

A software interrupt, (ie. a system call), that can change the state of thread/s. This encompasses sleep calls and calls to wait/signal on inter-thread synchro objects, as well as I/O calls that request data that is not immediately available.

If there is no interrupt, the OS cannot change the set of running threads because it is not entered. The OS does not know or care about loops, function/methods calls, (except those that make system calls as above), gotos or any other user-level flow-control mechanisms.

Upvotes: 0

zhiayang
zhiayang

Reputation: 571

I'm not an expert on .NET, but in general scheduling is handled by the kernel.

  1. Either your thread's timeslice has expired (threads/processes only get a certain amount of CPU time)

  2. Your thread has blocked for IO.

  3. Some other obscure reason, like waiting for an IPC message, a network packet or something.

Threads can be preempted at any point along their execution path, be it in a loop or returning from a function. This in general isn't handled by the underlying VM (.NET or JVM) but is controlled by the OS.

Upvotes: 5

Related Questions