The operating system can avoid busy wait of a process by putting it to sleep and restoring it in case of an event. For restoring the operating system needs to check on the event occurance, it means the operating system or some part of it is struck in busy wait ?
Is it possible to have a interrupt driven I/O in software context?
Only Between I/O and process not between processes.
For restoring the operating system needs to check on the event occurance, it means the operating system or some part of it is struck in busy wait?
No.
Is it possible to have a interrupt driven I/O in software context?
Yes.
Only Between I/O and process not between processes.
Yes.
Computers haven't used busy-wait for I/O since about 1957.
Related
In the book "Operating System Concept by SILBERSCHATZ, GALVIN & GAGNE", they've mentioned that,
Main Memory(Primary memory) and the registers built into the processor itself are the only storage that CPU can access directly
This statement has caused a lot of confusion. If CPU can not access Secondary Memory, then how does it fetch a program from Secondary Memory?
CPU can't access Secondary memory directly doesn't mean It can't access it anyway. when System is booted, BIOS inbuilt program (in ROM) copy boot loader (from secondary bootable device) to RAM's memory and ask cpu to continue execution from that particular address.
Once CPU starts executing Boot loader, Boot loader calls necessary function to read from disk (secondary storage) and copy your OS kernel image into memory. transfer of data is done through I/O ports.
You have your kernel image into memory, and thus boot loader ask cpu to jump to kernel's entry point. You have your kernel starting up this point.
Kernel setup OS environment, load up necessary drivers (including disk/cd-rom driver). After this point, It is up to OS disk driver that It performs I/O port operation or DMA access to load up data from secondary storage.
Generally DMA is preferred because It does not involve CPU for polling up data from device, but It is little difficult to code.
I hope I cleared your doubt :)
For one of my project the controller selection made was STM32L1 series. ST provides the drivers for USB, I2C, SPI etc. So while making a decision on RTOS is there any consideration needed to be given to the drivers. Or in another way after deciding an RTOS, is there any standard way of interfacing peripheral drivers of the microcontroller with RTOS?
No, microcontroller peripheral drivers and the RTOS are typically independent so compatibility doesn't need to be a consideration. The microcontroller peripheral drivers are basic drivers that aren't reliant on any RTOS services. In fact the peripheral library can be used without any RTOS. And an RTOS typically does not rely on any microcontroller peripherals beyond a timer. Even the setup of the timer is not built-in to the RTOS. The timer is typically setup by user code, before starting the RTOS.
If I haven't convinced you and you still want some assurance of compatibility then explore CMSIS.
While ST's low level drivers do not have RTOS dependencies or requirements, you might build a higer-level driver architecture around these using RTOS mechanisms to support mutual exclusion, buffering, and to manager handler priority for example.
You could for example manage multi-thread access to a device either through a device manager thread, or via mutual exclusion.
There is no standard defined way to interface peripheral drivers to an RTOS as it depends on the RTOS. However, a common way is to take advantage of blocking mutex or semaphore that are provided by the RTOS. A blocking mutex means that if a mutex is not available, a task will wait until it is free and not use any CPU time until then.
Usually when running an RTOS, you want the peripheral driver to grab the input data as quickly as possibly, using an interrupt, and then pass off the data to an RTOS task that can take its time processing the data. This is a nice clean way of managing peripheral interrupts and RTOS multitasking.
The general scenario is then you have a task that waits on the mutex. Most of the time it does not take any CPU time. When a peripheral driver gets invoked by an interrupt, the driver grabs the data off the hardware, and frees the mutex so the waiting task will wake up. The actual data can be passed between the peripheral driver and the task using global variable or other RTOS defined mechanism. Similar mechanism can be done using a semaphore.
The ST's provided peripheral drivers (whether it is StdPeripheralLib, HAL, or LL) can operate in this model. Therefore when making a decision on which RTOS to use, you should consider an RTOS with API that supports this model.
How is the receive message implemented internally in erlang runtime?
When the process is waiting for a message, the execution hang on the receive.
The receive is done via blocking IO, or asynchronous IO ?
If former, then it means the OS thread is blocked and if there are many process hang on receiving, the performance is bad in reason of thread context switch and also may reach the operation system's thread limitation.
Erlang processes are not corresponded to OS threads or processes. They are implemented as internal structures of Erlang VM and they are scheduled by Erlang VM. The number of OS threads which are started by Erlang VM by default is equal to CPU number. When the Erlang process is waiting for a message no one OS process or thread is blocked.
We have an application server developed with Delphi 2010 and Indy 10. This server receives more than 50 requests per second and it works well. But in some cases, it seems to me that Indy is very obscure. Their components are good, but sometimes I found myself digging into the source code only to understand a simple thing. Indy lacks on good documentation and good support.
The last thing that i came across was a big problem for me: I must detect when a client disconnects non gracefully (When the the client crashes or shutdown, for instance. Not telling the server that it will disconnect) and indy was not able to do that. If I want that, I will have to develop a algorithm like heartbeat, pooling or TCP keep-alive. I do not want to spend more time doing a, at least I think, component job. After a few study, I found out that this is not Indy's fault, but this is an issue of all blocking sockets components.
Now I am really thinking of changing the core of the Server to another good suite. I must admit I am tending to use a non-blocking socket. Based on that, I have some questions:
What do a benefit from changing from blocking to non-blocking sockets?
Will I be able to detect client disconnects (non gracefully)?
What component suite has the best product? By best product I mean: fast, good support, good tools and easy to implement.
I know this must be a subjective question, but I really want to hear that from you. My first question is the one I care most. I do not care if I have to pay 100, 500, 1000, 10000 dollars, but I want a complete solution. For now, I am thinking about Ip*works .
EDIT
I think some guys are not understand what I want. I don't want to create my own socket. I have been working with sockets for a long time and I am getting tired of it. Really.
And non-blocking sockets CAN detect client disconnects. That is a fact and it has good documentation all over the internet. A non-blocking socket checks the socket state for new incoming data all the time, and it makes possible to detect that the socket is not valid. This is not a heartbeat algorithm. A heartbeat algorithm is used on client side and it sends periodically packets (aka keep-alive) to the server to tells it is still alive.
EDIT
I am not make myself clear. Maybe because English is not my main language. I am not saying that it is possible to detect a dropped connection without trying to send or receiving data from a socket. What I am saying is that every non-blocking socket is able to do that because they constantly tries to read from the socket for new incoming data. Why is that so hard to understand? If you guys download and run ip*works demos, in special, the echoserver and echoclient ones (both use TCP) you can test by yourselves. I already tested it, and it works like I expected to do. Even if you use the old TCPSocketServer and TCPSocketClient in a non-blocking mode you will see what I meant.
"What do a benefit from changing from blocking to non-blocking sockets? Will I be able to detect client disconnects (non gracefully)?"
Just my two cents to get the ball rolling on this question - I'm not a socket EXPERT, but I do have a good deal of experience with them. If I'm mistaken, I'm sure someone will correct me... :-)
I assume that since you're running a server using blocking sockets with 50 connections per second, you have a threading mechanism in place to handle client requests. If so, you don't really stand to gain anything from non-blocking sockets. On the contrary - you will have to change your server logic to be event driven- based on events fired in your main thread from the non-blocking sockets, or use constant polling to know what your sockets are up to.
Non-blocking sockets can't detect clients disconnecting without notification any more than blocking sockets can - they don't have telepathic powers... The nature of the TCP/IP 'conversation' between client and server is the same - blocking and non-blocking is only with respect to your application's interaction with the socket connection conducting the 'conversation'.
If you need to purge dead connections, you need to implement a heartbeat or timeout mechanism on your socket (I've never seen a modern socket implementation that didn't support timeouts).
What do a benefit from changing from blocking to non-blocking sockets?
Increased speed, availability, and throughput (from my experience). I had an IndySockets client that was getting about 15 requests per second and when I went directly to asynchronous sockets the throughput increased to about 90 requests per second (on the same machine). In a separate benchmark test on a server at a data-center with a 30 Mbit connection I was able to get more than 300 requests per second.
Will I be able to detect client disconnects (non gracefully)?
That's one thing I haven't had to try yet, since all of my code has been on the client side.
What component suite has the best product? By best product I mean: fast, good support, good tools and easy to implement.
You can build your own socket client in a couple of days and it can be very robust and fast... much faster than most of the stuff I've seen "off the shelf". Feel free to take a look at my asynchronous socket client: http://codesprout.blogspot.com/2011/04/asynchronous-http-client.html
Update:
(Per Mikey's comments)
I'm asking you for a generic, technical explanation of how NBS increase throughput as opposed to a properly designed BS server.
Let's take a high load server as an example: say your server is supposed to handle 1000 connections at any given time, with blocking sockets you would have to create 1000 threads and even if they're mostly idle, the CPU will still spend a lot of time context switching. As the number of clients increases you will have to increase the number of threads in order to keep up and the CPU will inevitably increase the context switching. For every connection you establish with a blocking socket, you will incur the overhead of spawning of a new thread and you eventually you will incur the overhead of cleaning up after the thread. Of course, the first thing that comes to mind is: why not use the ThreadPool, you can reuse the threads and reduce the overhead of creating/cleaning-up of threads.
Here is how this is handled on Windows (hence the .NET connection): sure you could, but the first thing you'll notice with the .NET ThreadPool is that it has two types of threads and it's not a coincidence: user threads and I/O completion port threads. Asynchronous sockets use the IO completion ports which "allows a single thread to perform simultaneous I/O operations on different handles, or even simultaneous read and write operations on the same handle."(1) The I/O completion port threads are specifically designed to handle I/O in a much more efficient way than you would ever be able to achieve if you used the user threads in ThreadPool, unless you wrote your own kernel-mode driver.
"The completion port uses some special voodoo to make sure only a specific number of threads can run at once — if one thread blocks in kernel-mode, it will automatically start up another one."(2)
There are other advantages also: "in addition to the nonblocking advantage of the overlapped socket I/O, the other advantage is better performance because you save a buffer copy between the TCP stack buffer and the user buffer for each I/O call." (3)
I am using Indy and Synapse TCP libraries with good results for some years now, and did not find any showstoppers in them. I use the libraries in threads - client and server side, stability and performance was not a problem. (Six thousand request and response messages per second and more with the server running on the same system are typical.)
Blocking sockets are very useful if the protocol is more advanced than a simple 'send a string / receive a string'. Non-blocking sockets cause a higher coupling of message protocol handlers with the socket read / write logic, so I quickly moved away from non-blocking code.
No library can overcome the limitations of the TCP/IP protocol regarding detection of connection loss. Only trying to read or send data can tell wether the connection is still present.
In Windows, there is a third option which is overlapped I/O. Non-blocking sockets are essential a model using Windows messages developed to avoid single-threaded GUI apps to become "blocked" while waiting for data. A modern application IMHO would be better designed using threads and overlapped I/O.
See for example http://support.microsoft.com/kb/181611
Aahhrrgghh - the myth of being able to always detect "dropped" connections. If you pull the power on a machine with a client connection then the server cannot tell, without sending data, that the connection is "dead". The is through the design of the TCP protocol. Don't take my word for it - read this article (Detection of Half-Open (Dropped) TCP/IP Socket Connections).
This article explains the main differences between blocking and non-blocking:
Introduction to Indy, by Chad Z. Hower
Pros of Blocking
Easy to program - Blocking is very easy to program. All user code can
exist in one place, and in a
sequential order.
Easy to port to Unix - Since Unix uses blocking sockets, portable code
can be written easily. Indy uses this
fact to achieve its single source
solution.
Work well in threads - Since blocking sockets are sequential they
are inherently encapsulated and
therefore very easily used in threads.
Cons of Blocking
User Interface "Freeze" with clients - Blocking socket calls do not
return until they have accomplished
their task. When such calls are made
in the main thread of an application,
the application cannot process the
user interface messages. This causes
the User Interface to "freeze" because
the update, repaint and other messages
cannot be processed until the blocking
socket calls return control to the
applications message processing loop.
He also wrote:
Blocking is NOT Evil
Blocking sockets have been repeatedly
attacked with out warrant. Contrary to
popular belief, blocking sockets are
not evil.
It is not is an issue of all blocking sockets components that they are unable to detect a client disconnect. There is no technical advantage on the side of non-blocking components in this area.
I have windows 2003 terminal servers, multi-core. I'm looking for a way to monitor individual CPU core usage on these servers. It is possible for an end-user to have a run-away process (e.g. Internet Explorer or Outlook). The core for that process may spike to near 100% leaving the other cores 'normal'. Thus, the overall CPU usage on the server is just the total of all the cores or if 7 of the cores on a 8 core server are idle and the 8th is running at 100% then 1/8 = 12.5% usage.
What utility can I use to monitor multiple servers ? If the CPU usage for a core is "high" what would I use to determine the offending process and then how could I automatically kill that process if it was on the 'approved kill process' list?
A product from http://www.packettrap.com/ called PT360 would be perfect except they use SMNP to get data and SMNP appears to only give total CPU usage, it's not broken out by an individual core. Take a look at their Dashboard option with the CPU gauge 'gadget'. That's exactly what I need if only it worked at the core level.
Any ideas?
Individual CPU usage is available through the standard windows performance counters. You can monitor this in perfmon.
However, it won't give you the result you are looking for. Unless a thread/process has been explicitly bound to a single CPU then a run-away process will not spike one core to 100% while all the others idle. The run-away process will bounce around between all the processors. I don't know why windows schedules threads this way, presumably because there is no gain from forcing affinity and some loss due to having to handle interrupts on particular cores.
You can see this easily enough just in task manager. Watch the individual CPU graphs when you have a single compute bound process running.
You can give Spotlight on Windows a try. You can graphically drill into all sorts of performance and load indicators. Its freeware.
perfmon from Microsoft can monitor each individual CPU. perfmon also works remote and you can monitor farious aspects of Windows.
I'm not sure if it helps to find run-away processes because the Windows scheduler dos not execute a process always on the same CPU -> on your 8 CPU machine you will see 12.5 % usage on all CPU's if one process runs away.