Event-Driven State Thread Architecture for Modular Application Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Event-driven State Machine (EDSM) architecture is inefficient and complex, requiring significant processor time and resources to manage multiple modules or user sessions, making it difficult to design, program, and debug due to its monolithic nature and resource management challenges.
Innovation Solution
The implementation of event-driven state threads, where each module thread persists throughout the application's execution, maintaining its own state and resources, allowing for concurrent execution and reducing the burden on the main application by managing its own context and data, enabling efficient handling of user events without the need for frequent state updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If EDSM architecture is used to manage multiple modules or user sessions, then the application can handle multiple tasks, but the processor time and resource management complexity increases significantly
Solution Approach 1:
The patent divides the monolithic EDSM architecture into separate thread modules, where each thread handles a specific module or user session independently. This segmentation allows each thread to maintain its own state and resources without interfering with other threads, thereby reducing the overall complexity of resource management while preserving the ability to handle multiple tasks simultaneously.
2Productivity
If EDSM architecture is used to multiplex multiple modules, then resource sharing is achieved, but the difficulty of design, programming, and debugging increases
Solution Approach 1:
By segmenting the application into independent thread modules, each with its own state machine and event handling, the patent simplifies the design and programming process. Developers can work on individual threads independently without affecting others, making the system easier to program and debug while maintaining efficient resource sharing through the threaded architecture.
Solution Approach 2:
The patent introduces a thread manager as an intermediary that coordinates between multiple thread modules and the underlying system resources. This mediator handles the complexity of resource allocation and synchronization, allowing individual threads to remain simple and easy to program while still achieving efficient resource sharing through the intermediary's management.
3Ease of operation
If monolithic EDSM architecture is used, then centralized control is maintained, but processor efficiency decreases due to frequent context switching
Solution Approach 1:
The patent segments the centralized EDSM into distributed thread modules, where each thread maintains its own state and executes independently. This eliminates the need for frequent context switching between modules, as each thread has its own execution context. The segmented architecture preserves operational control through thread coordination mechanisms while significantly improving processor efficiency by reducing context switch overhead.
4Reliability
If EDSM manages state for each session internally, then complete state tracking is achieved, but the amount of processor time required increases
Solution Approach 1:
The patent segments the state management responsibility across multiple independent threads, where each thread maintains its own state internally rather than requiring centralized state management. This segmentation allows complete state tracking within each thread's isolated context while reducing processor time consumption by eliminating the overhead of centralized state management and frequent context switching between state-related operations.
Data Source
AI summary
An application framework is disclosed for handling predefined events for various application modules executing as threads. Events are received and associated with a thread and an event handling function. Event handling functions are classified as mutually exclusive and non-mutually exclusive. Mutually exclusive functions are blocked while another mutually exclusive function is executing. Event handling functions are processed by setting a corresponding thread to execute the function and placing the thread in a ‘non-wait’ state. Threads in the ‘non-wait’ state are then executed concurrently under the control of a system thread manger and are returned to a ‘wait’ state when the handling function ends. Each such thread maintains the session state throughout use of the application.