Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2001-03-02
2004-06-22
Iqbal, Nadeem (Department: 2114)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S025000, C714S032000, C714S036000, C714S038110, C714S047300
Reexamination Certificate
active
06754850
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the field of synchronizing software execution, e.g., synchronizing multi-threaded execution of a program. One embodiment of the invention also relates to the field of computer-based testing of products or devices.
DESCRIPTION OF THE RELATED ART
In the software arts, when working with multiple threads or processes, the problem of execution synchronization often arises. As used herein, execution synchronization may refer to any of various techniques enabling multiple threads or processes to execute together effectively. For example, one aspect of execution synchronization pertains to coordinating multiple threads or processes to share data or resources. For example, when one thread is writing to a file, other threads may need to be prevented from doing so at the same time in order to prevent data errors in the file. Also, threads may need to be prevented from reading from the file while it is being written to, in order to ensure that partial or incorrect data is not read.
Another aspect of execution synchronization pertains to defining and enforcing a series of operations that must be performed atomically. For example, consider a program where one thread updates a static data structure containing X and Y coordinates for items to be displayed by another thread. If the update thread alters the X coordinate for an item and is preempted before it can change the Y coordinate, the display thread may be scheduled before the Y coordinate is updated, resulting in the item being displayed at the wrong location.
Other aspects of execution synchronization include: forcing a group of threads to wait for each other until proceeding past a specified location; enabling threads to pass data to each other, e.g., so that a consumer thread can use data produced by a producer thread; notifying one or more threads when a particular event or condition occurs; etc.
In the prior art, various types of “synchronization objects” have been used in synchronizing execution among multiple threads and processes. For example, one type of synchronization object is a mutex. A mutex (short for mutual exclusion) may be used to guarantee exclusive access to a shared resource, typically by controlling access to the resource through “lock” and “unlock” operations. For example, referring to the above example of the update and display threads, to solve this X,Y coordinate update problem, the update thread may lock (acquire) a mutex indicating that the coordinate data structure is in use before performing the update. The update thread may then unlock (release) the mutex after both coordinates have been processed. The display thread must wait for the mutex to be unlocked before updating the display. This technique of waiting for a mutex is often called “blocking” on a mutex because the thread or process is blocked and cannot continue until the mutex is released. Other types of synchronization objects known in the prior art include semaphores and queues.
Programmers often find it difficult to properly implement execution synchronization using synchronization objects such as a rendezvous, mutex, or semaphore. For example, in the prior art, the programmer is typically responsible for coding and managing execution synchronization, including properly acquiring and releasing synchronization objects; defining and implementing timeout behavior when waiting to acquire a synchronization object; etc. In a complex application, this can require a significant amount of detailed work on the part of the programmer and can be difficult to accomplish.
Therefore, an improved system and method for synchronizing execution of software activities (i.e., processes or threads) is desired. It would be desirable for the improved system and method to simplify the task of implementing execution synchronization for an application. In particular, it would be desirable to abstract this task above the code-level, so that the programmer can work at a more intuitive level, e.g., using a graphical user interface (GUI). It would also be desirable to provide a method to work with a group or batch of threads at a higher level by defining “batch synchronization sections” operable to synchronize the execution of the batch of threads in various ways.
Execution synchronization is a common problem in many types of systems and software environments. One class of systems which has heretofore suffered from a lack of ability to manage execution synchronization is the class of computer-based “test executive” systems. In modern testing environments, software referred to as test executive software may be used to control or perform tests. The test executive typically allows the user to organize and execute a sequence of test modules, e.g., via a graphical user interface. For example, a test sequence may comprise a series of steps, wherein each step references a test module, and wherein each test module is executable to perform and/or control a test of one or more units under test (UUTs). Each step may have a parameter or property configuration that affects execution of the step. Test step parameters or properties may affect or control a wide variety of test aspects, such as whether data-logging is enabled for the test step, whether the step is executed in a loop, etc., as well as product-specific test aspects.
Thus, when executed, test modules corresponding to the steps in the test sequence may be operable to perform a desired sequence of tests on the unit under test. For example, various test modules may interact with instruments that measure and/or control the unit under test. For example, in a manufacturing environment, test executive software may be used to test manufactured products or devices, e.g., by executing various test modules that interact with instruments that measure and/or control the products.
Thus, test executive software operates as the control center for an automated test system. More specifically, the test executive allows the user to create, configure, and/or control test sequence execution for various test applications, such as production and manufacturing test applications. Test executive software typically includes various features, such as test sequencing based on pass/fail results, logging of test results, and report generation, among others.
The following comprises a glossary of test executive nomenclature used herein:
Code Module—A program module, such as a Windows Dynamic Link Library (.dll), Java class file, LabVIEW VI (.vi), etc., or other software object or component that includes one or more functions or procedures that perform a specific test or other action.
Test Module—A code module that performs a test.
Step—Any action, such as calling a test module or step module to perform a specific test, that the user can include within a sequence of other actions.
Step Module—The code module that a step calls.
Sequence—A series of steps that the user specifies for execution in a particular order. Whether and when a step is executed can depend on the results of previous steps.
Subsequence—A sequence that another sequence calls. The user specifies a subsequence call as a step in the calling sequence.
Sequence File—A file that contains the definition of one or more sequences.
Sequence Editor—A program that provides a graphical user interface for creating, editing, and debugging sequences.
Run-time Operator Interface—A program that provides a graphical user interface for executing sequences on a production station. A sequence editor and run-time operator interface can be separate application programs or different aspects of the same program.
Test Executive Engine—A module or set of modules that provide an API for creating, editing, executing, and debugging sequences. A sequence editor or run-time execution operator interface uses the services of a test executive engine.
Application Development Environment (ADE)—A programming environment such as LabVIEW, LabWindows/CVI, Microsoft Visual C++, Microsoft Visual Basic, Delphi, etc., in which the user can create test modules and run-time oper
Bellin Jon
Grey James
Melamed Douglas
Burgess Jason L.
Euripidou Christopher M
Hood Jeffrey C.
Iqbal Nadeem
Meyertons Hood Kivlin Kowert & Goetzel P.C.
LandOfFree
System and method for performing batch synchronization for a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for performing batch synchronization for a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for performing batch synchronization for a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3364995