Microsoft Technology Licensing, LLC

Huseyin Serkan Yildiz

John Joseph Duffy

Stephen Harris Toub

Igor Ostrovsky

Joseph E Hoag

Mike Liddell

Joe Duffy

Danny S Shih

Paul F Ringseth

Vance Palmer Morrison

Hazim Shafi

Massimo Mascaro

Mingtzong Lee

Edward George Essey

William T Colburn

Stephen S Toub

Aniket A Shah

Alexandre G Ferreira

Pooja Nagpal

Jose H Baldner

A parallel execution runtime prevents stack overflow by maintaining an inline counter for each thread executing tasks of a process. Each time that the runtime determines that inline execution of a task is desired on a thread, the runtime determines whether the inline counter for the corresponding thread indicates that stack overflow may occur. If not, the runtime increments the inline counter for the thread and allows the task to be executed inline. If the inline counter indicates a risk of stack overflow, then the runtime performs additional one or more checks using a previous stack pointer of the stack (i.e., a lowest known safe watermark), the current stack pointer, and memory boundaries of the stack. If the risk of stack overflow remains after all checks have been performed, the runtime prevents inline execution of the task.

Stack overflow prevention in parallel execution runtime

The present invention extends to methods, systems, and computer program products for indicating parallel operations with user-visible events. Event markers can be used to indicate an abstracted outer layer of execution as well as expose internal specifics of parallel processing systems, including systems that provide data parallelism. Event markers can be used to show a variety of execution characteristics including higher-level markers to indicate the beginning and end of an execution program (e.g., a query). Inside the execution program (query) individual fork/join operations can be indicated with sub-levels of markers to expose their operations. Additional decisions made by an execution engine, such as, for example, when elements initially yield, when queries overlap or nest, when the query is cancelled, when the query bails to sequential operation, when premature merging or re-partitioning are needed can also be exposed.

Indicating parallel operations with user-visible events

A method of performing a wait operation includes creating a first plurality of tasks and a continuation task. The continuation task represents a second plurality of tasks. The continuation task and each of the tasks in the first plurality have an associated wait handle. The wait handles for the first plurality of tasks and the continuation task are stored in an array. A wait operation is performed on the array, thereby waiting for at least one of the tasks in the first and second pluralities to complete.

Performing a wait operation to wait for one or more tasks to complete

A parallel execution runtime allows tasks to be executed concurrently in a runtime environment. The parallel execution runtime delegates the implementation of task queuing, dispatch, and thread management to one or more plug-in schedulers in a runtime environment of a computer system. The plug-in schedulers may be provided by user code or other suitable sources and include interfaces that operate in conjunction with the runtime. The runtime tracks the schedulers and maintains control of all aspects of the execution of tasks from user code including task initialization, task status, task waiting, task cancellation, task continuations, and task exception handling.

Plug-in task scheduler

A data partitioning interface provides procedure headings to create data partitions for processing data elements in parallel, and for obtaining data elements to process, without specifying the organizational structure of a data partitioning. A data partitioning implementation associated with the data partitioning interface provides operations to implement the interface procedures, and may also provide dynamic partitioning to facilitate load balancing.

Configurable partitioning of parallel data for parallel processing

A method of executing a loop over an integer index range of indices in a parallel manner includes assigning a plurality of index subsets of the integer index range to a corresponding plurality of threads, and defining for each index subset a start point of the index subset, an end point of the index subset, and a boundary point of the index subset positioned between the start point and the end point of the index subset. A portion of the index subset between the start point and the boundary point represents a private range and the portion of the index subset between the boundary point and the end point represents a public range. Loop code is executed by each thread based on the index subset of the integer index range assigned to the thread.

Parallel execution of a loop

A parallelism policy object provides a control parallelism interface whose implementation evaluates parallelism conditions that are left unspecified in the interface. User-defined and other parallelism policy procedures can make recommendations to a worker program for transitioning between sequential program execution and parallel execution. Parallelizing assistance values obtained at runtime can be used in the parallelism conditions on which the recommendations are based. A consistent parallelization policy can be employed across a range of parallel constructs, and inside recursive procedures.

Controlling parallelization of recursion using pluggable policies

The present invention extends to methods, systems, and computer program products for propagating unhandled exceptions in distributed execution environments, such as clusters. A job (e.g., a query) can include a series of computation steps that are executed on multiple compute nodes each processing parts of a distributed data set. Unhandled exceptions can be caught while computations are running on data partitions of different compute nodes. Unhandled exception objects can be stored in a serialized format in a compute node's local storage (or an alternate central location) along with auxiliary details such as the data partition being processed at the time. Stored serialized exception objects for a job can be harvested and aggregated in a single container object. The single container object can be passed back to the client.

Propagating unobserved exceptions in distributed execution environments

A process to detect video glitches and audio-video synchronization errors arising during playback or capture. The process encodes an external time stamp into video and audio streams directly at the output of a digital media playback device. The process captures the stamped video and audio streams and analyzes the external stamp by comparing it with a presentation time stamp and a capture time stamp.

Automatic video glitch detection and audio-video synchronization assessment

A method of handling an exception in a parallel system includes constructing a task object, executing a method with the task object, and catching an exception with the task object during execution of the method. The exception is propagated in response to the task object becoming inaccessible without the exception having been observed.

Propagating unobserved exceptions in a parallel system

The present invention extends to methods, systems, and computer program products for a structured task hierarchy for a parallel runtime. The parallel execution runtime environment permits flexible spawning and attachment of tasks to one another to form a task hierarchy. Parent tasks can be prevented from completing until any attached child sub-tasks complete. Exceptions can be aggregated in an exception array such that any aggregated exceptions for a task are available when the task completes. A shield mode is provided to prevent tasks from attaching to another task as child tasks.

Structured task hierarchy for a parallel runtime

An energy measurement system ('EMS') and techniques for correlating energy consumption to computing system activity. The EMS includes a data acquisition module, a processing module, and optionally a visualization module. The data acquisition module receives and transmits to the processing unit a number of sampled data streams, referred to as 'data acquisition traces,' associated with a computing system under test (&#x201c;SUT&#x201d;). The processing module concurrently receives one or more system traces from the SUT, which are produced by particular components under examination by the EMS. Synchronization is established between the data acquisition traces and the system trace(s) when the SUT executes certain predetermined actions to produce data in both the data acquisition traces and the system trace(s), which data is used to logically align the traces. Then, as test scenarios are executed by the SUT, changes are monitored in the traces, and energy consumption is quantified.

Growing community of inventors

Kenmore, WA, United States of America

Huseyin Serkan Yildiz