Latency-Hiding Context Management for Distributed Tasks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Distributed data processing systems face performance bottlenecks due to communication latency, particularly in large-scale graph processing where numerous concurrent tasks require remote data access, leading to underutilization of computational resources.

Innovation Solution

Implementing a context management system with request and companion buffers that allow worker threads to suspend tasks during remote data access, enabling efficient processing by sending request messages and resuming tasks upon response, thereby hiding communication latency.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If context switching with ready task queue and suspended task queue is implemented, then communication latency is hidden for small numbers of tasks, but the queues become a performance bottleneck when the number of remote data accesses and concurrent tasks is large

Engineering Contradiction:
Improvecommunication latencyVSAvoidprocessing throughput
Core Design Contradiction:
Loss of timeVSProductivity

Solution Approach 1:

The patent segments the task management system into multiple worker threads, each independently managing its own ready task queue and suspended task queue. This segmentation allows parallel processing of tasks across multiple threads, preventing any single queue from becoming a system-wide bottleneck. Each worker thread can independently select and execute tasks from its own ready queue without contention from other threads, thereby maintaining high processing throughput even with large numbers of concurrent tasks.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by pre-fetching remote data into local memory before it is strictly needed for computation. When a task is suspended waiting for remote data, the system proactively initiates data transfer operations in advance. This allows the computation to proceed as soon as the data arrives, rather than waiting passively, thereby reducing the effective communication latency impact on overall processing productivity.

Inventive Principle:
Principle #10Preliminary action

2Productivity

If the number of concurrent tasks is increased to utilize computation resources, then computational resource utilization improves, but communication latency acts as a bottleneck reducing scalability

Engineering Contradiction:
Improvecomputational resource utilizationVSAvoidcommunication latency impact
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent ensures continuity of useful action by maintaining multiple worker threads that continuously execute tasks without idle waiting periods. When one worker thread is blocked waiting for remote data, other threads continue processing their ready queues. The system also implements continuous pre-fetching of data in the background, ensuring that computational resources remain actively utilized rather than idle, thereby maintaining high productivity while overcoming communication latency bottlenecks through parallel continuous operation.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS9535756B2Latency-hiding context management for concurrent distributed tasks in a distributed system
Publication Date: 2017.01.03 ORACLE INT CORP
  • US9535756B2 patent drawing
  • US9535756B2 patent drawing
  • US9535756B2 patent drawing

AI summary

Techniques are provided for latency-hiding context management for concurrent distributed tasks. A plurality of task objects is processed, including a first task object corresponding to a first task that includes access to first data residing on a remote machine. A first access request is added to a request buffer. A first task reference identifying the first task object is added to a companion buffer. A request message including the request buffer is sent to the remote machine. A response message is received, including first response data responsive to the first access request. For each response of one or more responses of the response message, the response is read from the response message, a next task reference is read from the companion buffer, and a next task corresponding to the next task reference is continued based on the response. The first task is identified and continued.