Operating System Interprocess Message Unblocking Mechanism
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In message passing interprocess communication, client processes can be indefinitely blocked awaiting replies from server processes that fail to respond timely, posing challenges for safety-certified clients and increasing complexity, especially when dealing with non-safety-certified servers.
Innovation Solution
A mechanism is introduced where the operating system triggers actions to unblock client processes by sending requests and potentially setting further timeouts or initiating signals, such as POSIX signals, to ensure timely unblocking, even if server processes are not safety-certified, using a look-up table to define actions for non-responsive server processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If client processes wait indefinitely for replies from server processes, then message passing completeness is maintained, but client process blocking time increases indefinitely
Solution Approach 1:
The system performs preliminary actions by setting timeout values and monitoring mechanisms before the blocking becomes indefinite. The timeout mechanism is established in advance, and the system continuously monitors whether the timeout has been exceeded, allowing it to take corrective action (unblocking the client) before the blocking becomes permanent.
Solution Approach 2:
The system implements feedback through the timeout monitoring mechanism that continuously checks whether a server process has replied within the expected time frame. When the feedback indicates that the timeout has been exceeded without a reply, the system automatically triggers unblocking actions, creating a closed-loop control system that prevents indefinite blocking.
2Loss of time
If timeout mechanisms and unblocking actions are implemented, then client process blocking time is reduced, but system complexity increases
Solution Approach 1:
The system serves itself by automatically detecting timeout conditions and triggering unblocking actions without requiring external intervention or complex manual procedures. The timeout mechanism and monitoring system work autonomously to manage the blocking issue, reducing the need for additional complex control structures.
Solution Approach 2:
The timeout and unblocking mechanism serves multiple functions: it monitors server response times, detects blocking conditions, triggers unblocking actions, and maintains system reliability. This multi-functional approach consolidates several responsibilities into a single mechanism, reducing overall system complexity rather than increasing it.
3Reliability
If safety-certification is required for all server processes, then system reliability is improved, but device complexity and certification requirements increase
Solution Approach 1:
The timeout monitoring mechanism acts as an intermediary that protects client processes from unreliable server processes without requiring the server processes themselves to be safety-certified. This intermediary layer absorbs the reliability concern, allowing non-certified servers to operate while maintaining overall system reliability through the monitoring and unblocking mechanisms.
Solution Approach 2:
The system provides beforehand cushioning by establishing timeout values and monitoring mechanisms in advance to compensate for potential server unreliability. This preemptive protection allows the system to tolerate non-safety-certified servers by having safeguards ready to prevent indefinite blocking, thus maintaining reliability without requiring universal certification.
Data Source
Figure 1~2
Figure 3~4
Figure 5
AI summary
A thread of a client process may become blocked awaiting a reply to a message sent to a server process. Unblocking the client may include determining by the operating system that a timeout has expired without the server having replied to the message and then sending a request to the server process reply to the message to unblock the client. After sending the request for the server to reply to the message, the operating system may determine that the server has still not replied to the message after a further period has elapsed. If so, one or more actions related to the server process may be triggered. For example, a signal may be sent to the server process or the computer system may be rebooted.