Busy waiting vs. Blocking
Busy waiting is preferable when:
Scheduling overhead is larger than expected wait time.
Process resources are not needed for another tasks
Schedule -based blocking is inappropriate (e.g in OS kernel)
Chat with our AI personalities
When an interrupt occurs for which the process was waiting the OS should start executing the process. If the process isn't waiting for anything and there isn't anything for it to do, it might not start executing. Many processes in LINUX use a send/receive/reply IPC protocol. If the process is waiting for an IPC message from something else and has no timeout associated with the wait, it could effectively wait forever. In general, that's considered an error in programming.
In socket programming, there are two sides to every conversation: the listener (or server), and talker (the client).The server first opens a desired port, receives a socket handle, and begins listening for connections. It polls the socket every so often to listen for attempted connections by clients. Once a connection has been established, communication begins.A client merely indicates an IP address and port to connect to. Once the connection is made, communication begins.Then there are blocking and non-blocking sockets, which applies to both servers and clients. Blocking socketsforce the program to wait until there's activity before continuing its operation. So a server process will pause while waiting for a connection, and a client process will pause while waiting for the server to send data.Under most conditions, non-blocking sockets are preferred. This allows the program to give up timeslices to the operating system, as well as conduct any activities in the background like listening to multiple connections (for servers).Writing a socket program is about the same between Windows and Unix/Linux based systems, but there are some differences in setting up non-blocking sockets as well as initializing and closing the socket interface.More information on both Win32 and Linux socket programming can be found in the related links below.
In Wait for Graph the request edge is a directed edge Pi → Pj which indicates that process Pj is holding a resource that process Pi needs and thus Pi is waiting for Pj to release its lock on that resource. It does not have any allocation edge.In case of Resource Allocation Graph the request edge is a directed edge Pi → Rj which indicates that process Pi is requesting resource Rj. It has an allocation edge from Rj→Pk when the resource Rj is allocated to process Pk.The way the graphs are drawn are also different but both of them are used in deadlock detection.
A process or thread holding a resource while waiting to get hold of another resource
A thread is the sequence of instructions followed by a CPU, and is an independently dispachable unit in the run queue. A process can start and manage multiple threads, each managing an aspect of the overall processing. The operating system can schedule the threads independently, allowing them CPU time if they are ready, or blocking them if they are waiting on something, such as an IO completion. In a network process, such as a web server, there can be many things going on at the same concurrent time. Threads are an ideal solution to the problem of managing all of these things, because the main process does not need to poll each sub-process (thread) to see if it needs or is ready to do work.