Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Imagine that we have a computer that does nothing except waiting data from network and does some calculating on it when it is received.
Right now I think that there is no other way to do this besides
periodically checking some processor register that indicates that data is ready and then do computing. In my understanding under the hood network card receives the data, put it to the memory and by itself write to the cpu register that cpu can do computing. After the next
periodically check processor will compute stuff. Can you make explanation of what actually is happening in details (on hardware and in os). This question worries me for ages!
Also will be glad to see any materials about it!
The method described in the question of the processor periodically checking some data register is used and it called polling. Polling is often employed in simpler systems because it's simple to implement, but it has the downside of wasting cpu cycles checking for data that may or may not be there.
In practice though most modern operating systems are going to use a cpu hardware feature called interrupts in conjunction with the OS's scheduler. In the example of getting data from the network, the program will use some blocking read call that will wait for data to be received from the network. Once the read call is made the calling program will stop executing completely and the OS's scheduler will keep the program in the suspended state until data is received.
Often, the way a program signals that it wants to wants to stop executing until something happens (like a packet is received) is with a software construct called a semaphore (or similar mutual exclusion mechanism). However, in the case of networking code the semaphore is not directly accessed by the programmer.
When a packet is received by the network card the network card will store the packet into RAM somewhere. Once this is completed the network card triggers an interrupt to the CPU. The interrupt (generally) causes the CPU to stop executing whatever program may have been currently running and the CPU executes kernel code related to handling network activity. In this case it sends the received packet to the program that was waiting to receive the data.
Finally, the kernel uses the semaphore to signal the packet was received. The kernel then has the scheduler "wake up" the program that was waiting for the data from the network. The program can process the data, and then await the next set of data from the network.
If you want to learn more I'd recommend reading op on interrupts, scheduling and semaphores. These technique though are used for more than just networking. Many other IO devices are accessed in with similar approaches.
Related
I understand that using Hardware support for implementing preemptive scheduling is great for efficiency.
I want to know, What are practical ways we can do preemptive scheduling without taking support from hardware? I think one of way is Software Timers.
Also, Other way in multiprocessor system is using the one processor acting as master keep looking at slave processor's processor.
Consider, I'm fine with non-efficient way.
Please, elaborate all ways you think / know can work. Also, preferably but not necessarily works for single processor system.
In order to preempt a process, the operating system has to somehow get control of the CPU without the process's cooperation. Or viewed from the other perspective: The CPU has to somehow decide to stop running the process's code and start running the operating system's code.
Just like processes can't run at the same time as other processes, they can't run at the same time as the OS. The CPU executes instructions in order, that's all it knows. It doesn't run two things at once.
So, here are some reasons for the CPU to switch to executing operating system code instead of process code:
A hardware device sends an interrupt to this CPU - such as a timer, a keypress, a network packet, or a hard drive finishing its operation.
The software running on a different CPU sends an inter-processor interrupt to this CPU.
The running process decides to call a function in the operating system. Depending on the CPU architecture, it could work like a normal call, or it could work like a fake interrupt.
The running process executes an instruction which causes an exception, like accessing unmapped memory, or dividing by zero.
Some kind of hardware debugging interface is used to overwrite the instruction pointer, causing the CPU to suddenly execute different code.
The CPU is actually a simulation and the OS is interpreting the process code, in which case the OS can decide to stop interpreting whenever it wants.
If none of the above things happen, OS code doesn't run. Most OSes will re-evaluate which process should be running, when a hardware event occurs that causes a process to be woken up, and will also use a timer interrupt as a last resort to prevent one program hogging all the CPU time.
Generally, when OS code runs, it has no obligation to return to the same place it was called from. "Preemption" is simply when the OS decides to jump somewhere other than the place it was called from.
I have a question related to IOCP networking strategy for our C++ server application.
Our server simulates a lot of devices which speak over UDP with short (less than 2K) messages. The server is also bound by a soft real-time constraint of 70-100 milliseconds. Currently the networking part of the application was developed with a thread being started for every socket, which leads to hundreds of threads being started. Their job is to watch for the UDP sockets, and when the data arrives, copy it into the queue of our real-time thread.
We are being asked to support more and more devices and I was thinking that rewriting the communication module using IOCP our server would be more efficient. I developed a prototype based on the code I was able to find online, but the combination of
WSARecvFrom (Initiates receive)
GetQueuedCompletionStatus
OnDataRecieved (A method of my class that gets called when data is copied into my buffer)
does not seem efficient at all. The gaps between data arrival on a given socket are 500-600 milliseconds.
I only started prototyping and did not profile a whole lot.
My question are:
Can IOCP be used for my scenario or is it designed for high throughput only?
Will WSAAsyncSelect (with hidden windows) be more efficient for my use case?
Thanks in advance,
Michael
Edit:
I noticed while profiling that the problem starts with:
- WSASendTo
- GetQueuedCompletionStatus
- OnDataSent
Looks like GetQueuedCompletionStatus doesn't wake up fast enough.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
Okay as we know that a single processor can execute one instruction at one time, which means a single processor can execute either the Operating system's instruction or the user program's instruction at one time.
Now how is it possible that an operating system, and a user program can run at the same time in single processor?
Is cpu assigned to a user program when you open the program and when you close the user program the cpu is assigned back to the Operating system ??
Basically it is impossible to run two threads on a single processor core at once. However it is possible for the system to pretend to do this by swapping threads on and off the CPU. There are basically two ways to do this. Cooperative and Preemptive multitasking.
In the days of Windows 3, CPUs had a single core (I'm sure some big expensive machines had more but not that normal people got to see). Windows 3 didn't interrupt processes. What happened was processes had to periodically relinquish control to the OS. The OS would then continue the process again at a later time. This model is called cooperative multitasking.
Cooperative multitasking has a bit of an issue though. If a process fails to relinquish control to the OS (normally due to a bug) it can hog the system's resources and the system needs rebooting. This is why when Windows 95 was released Microsoft switched to a pre-emptive multitasking model.
With pre-emptive multitasking the hardware allows the OS to set an interrupt for a future time (how this is done varies by hardware system). This means that the OS can guarantee to get back on the CPU. When it does this, it stores the state (mainly the CPU registers) of the running thread and then loads a different one. This means that the OS always has control as it does not rely on the processes relinquishing control.
I'm sure other OS used pre-emptive multitasking before Windows 95 but it was Win 95 that really brought it to the mainstream on the PC.
Another issue that can occur is that one process tries to write to the memory used by another process, or a process tries to directly access some hardware without the operating system's permission. When the CPU starts up it is in Real Mode and loads the OS, the OS can then set up certain restrictions and switch the CPU to protected mode before running a process. While in protected mode the CPU will stop the process from accessing memory addresses and hardware that the OS has not allowed, forcing the process to call back to the OS to access these resources.
This is called Preemption or Time Slicing
In simple terms:
There are multi-threaded CPU's which can manage multiple threads (instructions)
But even that's not enough. The CPU has to split the workload, it does this by pausing a thread (called an interrupt) and working on another.
An average computer might have over a thousand threads running, but only 4 CPU Cores (which can only run 4 threads at a time)
How does it do it?
Some CPU's can only run 4 threads at a time, to manage all the other thousands of threads it must pause the thread and work on another and pause that and work on another, This is called Time Slicing time is not the only factor, priorities & usage come into play too. CPU's are really fast and can do this in < 1ms
EDIT: The "System Interrupts" is what manages all of this, it's not really a process in sense but this piece of windows is what controls all thread execution
Here a simple explanation from : http://doc.qt.io/qt-5/thread-basics.html:
So how is concurrency implemented? Parallel work on single core CPUs
is an illusion which is somewhat similar to the illusion of moving
images in cinema. For processes, the illusion is produced by
interrupting the processor's work on one process after a very short
time. Then the processor moves on to the next process. In order to
switch between processes, the current program counter is saved and the
next processor's program counter is loaded.
I am working on implementing a VM and trying to model all the different hardware components as accurately as possible, just for pure learning purposes.
My question is, how does a DMA device handle multiple concurrent transfer requests? From what I understand a DMA device has several registers to set the location in memory, the type of operation (read or write) and the number of bytes, so what happens when the CPU requests an operation from DMA, puts the thread to sleep and then the next thread that runs also requests a DMA operation while the previous one is still in progress? Is this even supported?
Unless you're talking about ancient, ISA-era hardware, DMA nowadays is handled by the device itself taking ownership of the bus and requesting the data directly from the RAM. See the Wikipedia article on Bus Mastering for more information.
Therefore, it is really up to any individual device how to handle DMA, so not much can be said for the general case. However, most simple devices just support a single DMA operation at a time; if the host wants to submit two DMA operations, it would simply wait for the first DMA to complete (being notified by an interrupt) and then instruct the device to do the second one, the OS putting the requesting thread to sleep while the first DMA is in progress. There are certainly variations, however, such as using a command-buffer that can specify multiple (DMA-involving or not) operations for the device to do in sequence without interrupting the CPU between each.
I doubt there are very many devices at all that try to carry out multiple transfers simultaneously, however, seeing as how interleaving DRAM accesses would just hurt performance anyway. But I wouldn't exclude their existence, especially if the operations involve very large transfers.
In the end, you'll just have to read up on the particular device you're trying to emulate.
an event is when you click on something, and code is run right away
polling is when the application constantly checks if your mouse button is held down, and if it's held down in a certain spot, code is run
do events really exist in computing, or is it all a layer built on polling?
This is a complicated question, and the answer depends on how far down you go (in abstraction layers) to answer it. Ultimately, your USB keyboard device is being polled once per millisecond by the computer to ask what keys are being held down. This information gets passed to the keyboard driver through a CPU interrupt when the USB device (in the computer) gets a packet of data from the keyboard. From then on, interrupts are used to pass the data from process to process (through the GUI framework) and eventually reach your application.
As Marc Cohen said in his answer, CPU interrupts are also raised to signal I/O completion. This is an example of something which has no polling until you get to the hardware level, where checks are performed (perhaps once per clock cycle? Someone with more experience with computer architecture should answer) to see if the event has taken place.
It's a common technique to simulate events by polling but that's often very inefficient and leads to a dilemma where you have a tradeoff between event resolution and polling overhead but that doesn't mean true events don't exist.
A CPU interrupt, which could be raised to signal an external event, like I/O completion, is an example of an event all the way down at the hardware layer.
Well, both operating system and application level depend on events not polling. Polling is usually possible where states cannot be maintained. On desktop applications and OS levels however, applications have states; so, they use events for their processes, not polling.