0

If you have a lot of threads with things to do, then apparently asynchronous calls aren't necessarily better than synchronous calls because blocking threads just hand the rest of their time over to the next thread in line (if any) according to the answers to this question.

My question is when does windows decide a call is blocking? Presumably not every call to a database, file system or the tcp/ip stack is blocking, because otherwise all such calls would take at least 10 milliseconds to complete (because the thread would give up the rest of its time slice, which is around 10 milliseconds long). However, we certainly have database calls that take less time than that to complete.

So how does windows wait to determine whether a call is, indeed, blocking and how much time is lost determining that a call is, in fact, blocking (e.g. does windows use a small timeout to determine whether a database or other resource call is, in fact, blocking).

My real reason for asking is to better understand how it works so I can more clearly understand synchronous vs asynchronous call tradeoffs.

Community
  • 1
  • 1

4 Answers4

1

you wrote because otherwise all such calls would take at least 10 milliseconds to complete (because the thread would give up the rest of its time slice, which is around 10 milliseconds long)

this is not true.

the thread is blocked (due to IO) -> looses rest of time slice

lets say, after 1 MS the block ended, and windows reschedule the thread to the execution queue...

let say, after 2 MS the thread is running again (which is reasonable if all running threads do many IO calls.. which means they end early).

you call took 3 MS to end...

Shlomi Borovitz
  • 1,700
  • 9
  • 9
  • Very Interesting point. If all threads are doing lots of IO, I see that changes things. Are you also saying that is the only mechanism by which an IO or database call ends up taking less than a time slice? i.e. are you saying all IO and database calls do, in fact, block and give up the threads time slice? –  Mar 05 '14 at 18:51
  • not only if all thread doing allot of IO.. if you'll check Task manager, you'll see that the CPU is idle most of the time. so when the block ends, your thread would be scheduled almost immediately – Shlomi Borovitz Mar 05 '14 at 19:16
1

At the lowest level, all IO is going to be asynchronous, not synchronous.

All of the blocking methods that you have to access IO are simply using some type of synchronization mechanism (i.e. a Semaphore) to block the thread until the IO is complete.

When you have an API providing asynchronous IO access (unless it's poorly written) it's not taking that synchronous method and making it asynchronous, it's just exposing the underlying asynchrony of the IO and skipping the step where it blocks until it's done.

Servy
  • 202,030
  • 26
  • 332
  • 449
1

Typically, when you initiate an IO request, a call goes down to the kernel and to the device drivers. If the request can be satisfied immediately (for example, because of caching) then it will be.

In this scenario, when the synchronous IO function asks the kernel to wait for the IO to complete, the wait is satisfied immediately and the thread does not block.

If the wait is not satisfied immediately, Windows might or might not spinlock briefly before changing thread context. That's an undocumented implementation detail which may vary from case to case.

Note that it doesn't matter whether you are using synchronous or asynchronous functions; the only difference is which code asks the kernel to wait. The behaviour will be the same either way.

Asynchronous calls may provide some performance advantage over using synchronous calls and multiple threads, because if several IO operations complete at once, you can process the results for all of them without having to switch thread context. They may also allow you to structure your program in a more convenient way; obviously, this depends on your particular needs. The latter is usually more important.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
0

'when does windows decide a call is blocking?

Easy - whenever it asks for a resource that is not available immediately.

'because otherwise all such calls would take at least 10 milliseconds to complete (because the thread would give up the rest of its time slice, which is around 10 milliseconds long).

You do not understand how preemptive multitaskers work - you have probably been misled by the many, hopelessly-misleading 'thread-primer-101' sites/books. The timer interrupt is just one of many interrupt sources that can change the state of threads. Hardware interrupts from non-timer peripherals that cause drivers to run, and inter-thread comms calls, can initiate a scheduler run and make threads ready that were waiting.

My advice is to immediately close, and destroy links to, all such sites that contain the keywords/phrases 'quantum', 'time-slice', 'round-robin', 'give up the remainder'. Also, any sites that mention the timer interrupt before any others, or don't mention the other interrupts at all.

All such sites are crap, and there are a lot of them.

Martin James
  • 24,453
  • 3
  • 36
  • 60
  • What references or sites would you recommend as providing correct information and unraveling myths? –  Mar 07 '14 at 16:36