I heard that there are two ways for reading a file in assembly language: one requires CPU to repeatedly query disk reading finishing state in a cycle; the other way uses interrupt callback when disk reading is finished, and do not require CPU during the reading process.
What I want to know is: if I read a large chunck of data - such as gigabytes - from a file using WinAPI readFile, would it occupy much CPU time for disk state query?
I think the OP is referring to the difference between disk drivers that perform polling vs interrupt driven drivers.
Drivers that use polling almost always do so at the lowest possible priority - essentially at the same priority as Windows' idle thread. Also these drivers are quite rare. They'd only be appropriate on a system where throughput was much more important than response time.
While a polling driver may take a lot of CPU cycles on a lightly loaded system, it won't take time away from more important tasks (and everything will be more important). And it's usage of the CPU won't be reflected in utilities like Taskmgr. In effect you probably won't know it's using a lot of cycles.
The method the driver uses to determine whether I/Os have completed has nothing to do with whether an app uses ReadFile or not. An app doesn't have any choice in how the disk driver operates. If the app needs to access files on the disk the driver controllers, then it's gotta (indirectly) use the driver for that disk.
As an application developer you really have two choices: ReadFile (almost all other read APIs end up going through this API) or memory mapped I/O. Understanding the tradeoffs between the two is best achieved by googling and looking up the topic on MSDN.