Multi-Version Runtime Library Switching in Distributed Nodes

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing distributed computing systems face challenges in efficiently processing job requests across multiple versions of a service, particularly in cloud environments, where rapid context switching and resource allocation overheads lead to latency and inefficiencies in handling diverse service versions.

Innovation Solution

A mechanism where service processing nodes utilize a centralized store to quickly access and switch between multiple runtime libraries, allowing concurrent or interleaved execution of job requests across different service versions, enabling efficient processing of job requests as compiler, scheduler, or worker nodes by loading appropriate executables and libraries as needed.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a service processing node runs multiple versions of a distributed computerized service simultaneously, then the versatility and adaptability of the system is improved, but the device complexity and resource allocation overhead increase

Engineering Contradiction:

Improveability to process multiple service versionsVSAvoidcomplexity of managing multiple runtime libraries

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The service processing node is designed to perform multiple functions by running multiple versions of the distributed computerized service simultaneously. Each processing node can execute different runtime libraries (e.g., first runtime library, second runtime library) corresponding to different service versions, allowing a single node to serve multiple versions of the service rather than requiring separate dedicated nodes for each version.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system pre-loads and maintains multiple runtime libraries in memory before processing job requests. By having the runtime libraries already allocated and ready in the service processing node, the system avoids the overhead of dynamically loading and unloading libraries during request processing, thus reducing context switching time and resource allocation overhead while maintaining the ability to handle multiple service versions.

Inventive Principle:

Principle #10Preliminary action

2Productivity

If runtime libraries are quickly switched between different service versions, then the productivity and query performance are improved, but the loss of time and context switching overhead increase

Engineering Contradiction:

Improveprocessing speed of job requestsVSAvoidcontext switching time between service versions

Core Design Contradiction:

ProductivityVSLoss of time

Solution Approach 1:

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The service processing node continuously maintains multiple runtime libraries in memory simultaneously, allowing for rapid switching between different service versions without interruption. This continuous availability of multiple versions enables the system to process job requests from different service versions without the delays associated with loading or unloading libraries during context switching.

Inventive Principle:

Principle #20Continuity of useful action

Data Source

PatentUS10749984B2Processing requests for multi-versioned service

Publication Date: 2020.08.18 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

Processing a job request for multiple versions of a distributed computing service. The service processing node does this by at least interleavingly (e.g., via time sharing with rapid context switching, or by actually concurrently) running a first runtime library associated with a first service version of the distributed computerized service and a second runtime library associated with a different service version of the distributed computerized service. While running the first runtime library, job requests of a first service version may be at least partially processed using a first set of one or more executables that interact with the first runtime library. While running the second runtime library, job requests of a second service version may be at least partially processed using a second set of one or more executables that interact with the second runtime library.