US20110167425A1 - Instrument-based distributed computing systems - Google Patents

Abstract

An instrument-based distributed computing system is disclosed that accelerates the measurement, analysis, verification and validation of data in a distributed computing environment. A large computing work can be performed in a distributed fashion using the instrument-based distributed system. The instrument-based distributed system may include a client that creates a job. The job may include one or more tasks. The client may distribute a portion of the job to one or more remote workers on a network. The client may reside in an instrument. One or more workers may also reside in instruments. The workers execute the received portion of the job and may return execution results to the client. As such, the present invention allows the use of instrument-based distributed system on a network to conduct the job and facilitate decreasing the time for executing the job.

Description

RELATED APPLICATION
• This application is a continuation of a pending United States patent application entitled “INSTRUMENT BASED DISTRIBUTED COMPUTING SYSTEMS”, U.S. patent application Ser. No. 11/301061, filed on Dec. 12, 2005.
TECHNICAL FIELD
• The present invention generally relates to a distributed computing environment and more particularly to methods, systems and mediums for providing an instrument-based distributed computing system that accelerates the measurement, analysis, verification and validation of data in the distributed computing environment.
BACKGROUND INFORMATION
• MATLAB® is a product of The MathWorks, Inc. of Natick, Mass., which provides engineers, scientists, mathematicians, and educators across a diverse range of industries with an environment for technical computing applications. MATLAB® is an intuitive high performance language and technical computing environment that provides mathematical and graphical tools for mathematical computation, data analysis, visualization and algorithm development. MATLAB® integrates numerical analysis, matrix computation, signal processing, and graphics in an easy-to-use environment where problems and solutions are expressed in familiar mathematical notation, without traditional programming. MATLAB® is used to solve complex engineering and scientific problems by developing mathematical models that simulate the problem. A model is prototyped, tested and analyzed by running the model under multiple boundary conditions, data parameters, or just a number of initial guesses. In MATLAB®, one can easily modify the model, plot a new variable or reformulate the problem in a rapid interactive fashion that is typically not feasible in a non-interpreted programming such as Fortran or C.
• As a desktop application, MATLAB® allows scientists and engineers to interactively perform complex analysis and modeling in their familiar workstation environment. With many engineering and scientific problems requiring larger and more complex modeling, computations accordingly become more resource intensive and time-consuming. However, a single workstation can be limiting to the size of the problem that can be solved, because of the relationship of the computing power of the workstation to the computing power necessary to execute computing intensive iterative processing of complex problems in a reasonable time. For example, a simulation of a large complex aircraft model may take a reasonable time to run with a single computation with a specified set of parameters. However, the analysis of the problem may also require the model be computed multiple times with a different set of parameters, e.g., at one-hundred different altitude levels and fifty different aircraft weights, to understand the behavior of the model under varied conditions. This would require five-thousand computations to analyze the problem as desired and the single computer would take an unreasonable or undesirable amount of time to perform these simulations. Therefore, it is desirable to perform a computation in a distributed manner when the computation becomes so large and complex that it cannot be completed in a reasonable amount of time on a single computer. In particular, since some instruments are provided on a PC-based platform and have capacities to run additional software, it is also desirable to use the instruments for performing a large computation in a distributed manner.
SUMMARY OF THE INVENTION
• The present invention provides an instrument-based distributed computing system that accelerates the measurement, analysis, verification and validation of data in a distributed computing environment. In the present invention, a large computational job can be performed in a distributed fashion using the instrument-based distributed system. The instrument-based distributed system may include a client that creates a job. The job may include one or more tasks. The client may distribute a portion of the job to one or more remote workers for the distributed execution of the job. The client may reside in an instrument. The workers may also reside in instruments. The workers execute the received portion of the job and may return execution results to the client. As such, the present invention allows the use of instrument-based distributed system on a network to conduct the job and facilitate decreasing the time for executing the job.
• In one aspect of the present invention, a method is provided for executing a job in a distributed fashion. The method includes the step of installing a computing client for providing a computing environment in an instrument. The method also includes the step of enabling the client to generate a job in the computing environment, wherein the job includes one or more tasks. The method further includes the step of distributing the job to remote computing workers for the distributed execution of the job.
• In another aspect of the present invention, a method is provided for executing a job in a distributed fashion. The method includes the step of installing a computing worker for providing a computing environment in the instrument. The method also includes the step of receiving a portion of a job generated by a remote client, wherein the job includes one or more tasks. The method further includes the steps of enabling the computing worker to execute the received portion of the job, and returning execution result to the remote client.
• In another aspect of the present invention, a system is provided for executing a job in a distributed fashion in a computing environment. The system includes a first instrument for generating a job, wherein the job includes one or more tasks. The system also includes a second instrument for receiving a portion of the job and executing the received portion of the job to obtain execution results, wherein the second instrument returns the execution results to the first instrument.
• In another aspect of the present invention, a medium holding instructions executable in an instrument is provided for a method of executing a job in a distributed fashion. The method includes the step of installing a computing client for providing a computing environment in the instrument. The method also includes the step of enabling the client to generate a job in the computing environment, wherein the job includes one or more tasks. The method further includes the step of distributing the job to remote computing workers for the distributed execution of the job.
• In another aspect of the present invention, a medium holding instructions executable in an instrument is provided for a method of executing a job in a distributed fashion. The method includes the step of installing a computing worker for providing a computing environment in the instrument. The method also includes the step of receiving a portion of a job generated by a remote client, wherein the job includes one or more tasks. The method further includes the steps of enabling the computing worker to execute the received portion of the job, and returning execution result to the remote client.
• The details of various embodiments of the invention are set forth in the accompanying drawings and the description below. Other features and advantages of the invention will become apparent from the description, the drawings and the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
• The foregoing and other objects, aspects, features, and advantages of the invention will become more apparent and may be better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:
• FIG. 1A is a block diagram of a computing device for practicing an embodiment of the present invention;
• FIG. 1B is a block diagram of a distributed computing system for practicing an illustrative embodiment of the present invention;
• FIG. 2A is a block diagram of the components of an embodiment of the present invention in a two-node networked computer system;
• FIG. 2B is a block diagram of the components of an alternative embodiment of the present invention in a multi-tier networked computer system;
• FIG. 2C is a block diagram of the components of an exemplary embodiment of the present invention in a distributed network computer system.
• FIG. 3A is a block diagram of the direct distribution mode of operation of the present invention;
• FIG. 3B is a block diagram of the automatic distribution mode of operation of the present invention;
• FIG. 3C is a block diagram of the batch automatic distribution mode of operation of the present invention;
• FIG. 3D is a block diagram of an exemplary embodiment of the batch automatic distribution mode of operation of the present invention;
• FIG. 4 is a block diagram illustrating a multiple mode of operation embodiment of the present invention;
• FIG. 5A is a flow diagram of steps performed in an embodiment ofFIG. 3A;
• FIG. 5B is a flow diagram of steps performed in an embodiment ofFIG. 3B;
• FIG. 5C andFIG. 5D are flow diagrams of steps performed in a batch mode of operations of the present invention;
• FIG. 6A is a block diagram depicting the details of the automatic task distribution mechanism;
• FIG. 6B is a block diagram depicting the details of the automatic task distribution mechanism with a job manager;
• FIG. 6C is a block diagram depicting the details of a job manager comprising the automatic task distribution mechanism;
• FIG. 7 is a block diagram depicting an exemplary embodiment of the invention using service processes;
• FIG. 8A is a block diagram illustrating the use of objects for user interaction with the distributed system;
• FIG. 8B is a block diagram illustrating the use of objects for user interaction with an exemplary embodiment of the distributed system;
• FIG. 9A is a block diagram illustrating an operation of the present invention for distributed and streaming technical computing;
• FIG. 9B is a block diagram illustrating an operation of the present invention for parallel technical computing;
• FIG. 10 is a block diagram showing an exemplary distributed system in the illustrative embodiment of the present invention;
• FIG. 11 is a block diagram showing an exemplary instrument depicted inFIG. 10;
• FIGS. 12A-12C are block diagrams showing other exemplary distributed systems in the illustrative embodiment of the present invention;
• FIG. 13 is a block diagram showing an exemplary test environment in the illustrative embodiment of the present invention;
• FIG. 14 a flow chart of steps performed in the distributed test system inFIG. 13; and
• FIG. 15 is a flow chart showing an exemplary operation for providing a distributed array in the illustrative embodiment of the present invention.
DETAILED DESCRIPTION
• Certain embodiments of the present invention are described below. It is, however, expressly noted that the present invention is not limited to these embodiments, but rather the intention is that additions and modifications to what is expressly described herein also are included within the scope of the invention. Moreover, it is to be understood that the features of the various embodiments described herein are not mutually exclusive and can exist in various combinations and permutations, even if such combinations or permutations are not made express herein, without departing from the spirit and scope of the invention.
• The illustrative embodiment of the present invention provides a distributed computing environment that enables a user to execute a job in a distributed fashion. In particular, the illustrative embodiment of the present invention provides an instrument-based distributed computing system that uses the one or more instruments for the distributed execution of the job. The instrument-based distributed computing system may include a client for creating the job. The client may distribute a portion of the job to one or more remote workers for the distributed execution of the job. The client may reside in an instrument. The workers may also reside in instruments. The remote workers execute a portion of the job and return the execution results to the client. The instruments running the workers may have the capability to accelerate the execution of the job. For example, the instrument may include hardware components, such as FPGA, ASIC, DSP and CPU, to perform fast calculations, such as FFT calculations. As such, the illustrative embodiment of the present invention executes the job in a distributed fashion using the instrument-based distributed computing system. The illustrative embodiment of the present invention utilizes a technical computing client and a technical computing worker for the distributed execution of the job, which will be described below in more detail.
• A. Technical Computing Client and Technical Computing Worker
• The illustrative embodiment of the present invention provides for the dynamic distribution of technical computing tasks from a technical computing client to remote technical computing workers for execution of the tasks on multiple computers systems. Tasks can be declared on a technical computing client and additionally organized into jobs. A job is a logical unit of activities, or tasks that are processed and/or managed collectively. A task defines a technical computing command, such as a MATLAB® command, to be executed, and the number of arguments and any input data to the arguments. A job is a group of one or more tasks. The task can be directly distributed by the technical computing client to one or more technical computing workers. A technical computing worker performs technical computing on a task and may return a result to the technical computing client.
• Additionally, a task or a group of tasks, in a job, can be submitted to an automatic task distribution mechanism to distribute the one or more tasks automatically to one or more technical computing workers providing technical computing services. The technical computing client does not need to specify or have knowledge of the technical computing workers in order for the task to be distributed to and computed by a technical computing worker. The automatic task distribution mechanism can distribute tasks to technical computing workers that are anonymous to any technical computing clients. The technical computing workers perform the task and may return as a result the output data generated from the execution of the task. The result may be returned to the automatic task distribution mechanism, which, in turn, may provide the result to the technical computing client.
• Furthermore, the illustrative embodiment provides for an object-oriented interface in a technical computing environment to dynamically distribute tasks or jobs directly or indirectly, via the automatic task distribution mechanism, to one or more technical computing workers. The object-oriented interface provides a programming interface for a technical computing client to distribute tasks for processing by technical computer workers.
• The illustrative embodiment will be described solely for illustrative purposes relative to a MATLAB®-based distributed technical computing environment. Although the illustrative embodiment will be described relative to a MATLAB®-based application, one of ordinary skill in the art will appreciate that the present invention may be applied to distributing the processing of technical computing tasks with other technical computing environments, such as technical computing environments using software products of LabVIEW® or MATRIXx from National Instruments, Inc., or Mathematica® from Wolfram Research, Inc., or Mathcad of Mathsoft Engineering & Education Inc., or Maple™ from Maplesoft, a division of Waterloo Maple Inc.
• The illustrative embodiment of the present invention provides for conducting a test in a distributed fashion tasks from a technical computing client to remote technical computing workers for execution of the tasks on multiple computers systems. Tasks can be declared on a technical computing client and additionally organized into jobs. A job is a logical unit of activities, or tasks that are processed and/or managed collectively. A task defines a technical computing command, such as a MATLAB® command, to be executed, and the number of arguments and any input data to the arguments. A job is a group of one or more tasks. The task can be directly distributed by the technical computing client to one or more technical computing workers. A technical computing worker performs technical computing on a task and may return a result to the technical computing client.
• Additionally, a task or a group of tasks, in a job, can be submitted to an automatic task distribution mechanism to distribute the one or more tasks automatically to one or more technical computing workers providing technical computing services. The technical computing client does not need to specify or have knowledge of the technical computing workers in order for the task to be distributed to and computed by a technical computing worker. The automatic task distribution mechanism can distribute tasks to technical computing workers that are anonymous to any technical computing clients. The technical computing workers perform the task and may return as a result the output data generated from the execution of the task. The result may be returned to the automatic task distribution mechanism, which, in turn, may provide the result to the technical computing client.
• Furthermore, the illustrative embodiment provides for an object-oriented interface in a technical computing environment to dynamically distribute tasks or jobs directly or indirectly, via the automatic task distribution mechanism, to one or more technical computing workers. The object-oriented interface provides a programming interface for a technical computing client to distribute tasks for processing by technical computer workers.
• FIG. 1A depicts an environment suitable for practicing an illustrative embodiment of the present invention. The environment includes acomputing device102 havingmemory106, on which software according to one embodiment of the present invention may be stored, a processor (CPU)104 for executing software stored in thememory106, and other programs for controlling system hardware. Thememory106 may comprise a computer system memory or random access memory such as DRAM, SRAM, EDO RAM, etc. Thememory106 may comprise other types of memory as well, or combinations thereof. A human user may interact with thecomputing device102 through avisual display device114 such as a computer monitor, which may include a graphical user interface (GUI). Thecomputing device102 may include other I/O devices such akeyboard110 and apointing device112, for example a mouse, for receiving input from a user. Optionally, thekeyboard110 and thepointing device112 may be connected to thevisual display device114. Thecomputing device102 may include other suitable conventional I/O peripherals. Thecomputing device102 may support anysuitable installation medium116, a CD-ROM, floppy disks, tape device, USB device, hard-drive or any other device suitable for installing software programs, such as the MATLAB®-based distributedcomputing application120. Thecomputing device102 may further comprise astorage device108, such as a hard-drive or CD-ROM, for storing an operating system and other related software, and for storing application software programs, such as the MATLAB®-based distributedcomputing application120 of an embodiment of the present invention. Additionally, the operating system and the MATLAB®-based distributedcomputing application120 of the present invention can be run from a bootable CD, such as, for example, KNOPPIX®, a bootable CD for GNU/Linux.
• Additionally, thecomputing device102 may include anetwork interface118 to interface to a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above. Thenetwork interface118 may comprise a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing thecomputing device118 to any type of network capable of communication and performing the operations described herein. Moreover, thecomputing device102 may be any computer system such as a workstation, desktop computer, server, laptop, handheld computer or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described herein.
• FIG. 1A depicts the MATLAB®-based distributedcomputing application120 of an embodiment of the present invention running in a stand-alone system configuration of asingle computing device102.FIG. 1B depicts another environment suitable for practicing an illustrative embodiment of the present invention, where functionality of the MATLAB®-based distributedcomputing application120 is distributed across multiple computing devices (102′,102″ and102′″). In a broad overview, thesystem100 depicts a multiple-tier or n-tier networked computer system for performing distributed software applications such as the distributed technical computing environment of the present invention. Thesystem100 includes a client150 (e.g., afirst computing device102′) in communications through anetwork communication channel130 with aserver computer160, also known as a server, (e.g., asecond computing device102″) over anetwork140 and the server in communications through anetwork communications channel130 with a workstation (e.g., athird computing device102′″) over thenetwork140′. Theclient150, theserver160, and theworkstation170 can be connected130 to thenetworks140 and/or140′ through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56 kb, X.25), broadband connections (e.g., ISDN, Frame Relay, ATM), wireless connections, or some combination of any or all of the above. Each of theclient150,server160 andworkstation170 can be any type of computing device (102′,102″ and102′″) as described above and respectively configured to be capable of computing and communicating the operations described herein.
• In one embodiment, each of theclient150,server160 andworkstation170 are configured to and capable of running at least a portion of the present invention of the MATLAB®-based distributedcomputing application120. As a distributed software application, the MATLAB®-based distributed computing application has one or more software components that run on each of theclient150,server160 andworkstation170, respectively, and work in communication and in collaboration with each other to meet the functionality of the overall application. For example, theclient150 may hold a graphical modeling environment that is capable of specifying block diagram models and technical computing tasks to analyze the model. Theclient150 may have software components configured to and capable of submitting the tasks to theserver160. Theserver160 may have software components configured to and capable of receiving the tasks submitted by theclient150 and for determining aworkstation170 to assign the task for technical computing. Theworkstation170 may hold software components capable of providing a technical computing environment to perform technical computing of the tasks assigned from theserver160 and submitted by theclient150. In summary, the technical computing environment and software components of the MATLAB®-based distributedcomputing application120 may be deployed across one or more different computing devices in various network topologies and configurations.
• FIG. 2A depicts an illustrative embodiment of the components of the MATLAB®-based distributedcomputing application120. In brief overview, thesystem200 of the MATLAB®-based distributedcomputing application120 is a two-node distributed system comprising a technicalcomputing client application250, or technical computing client, running on aclient150 computer and a technicalcomputing worker application270, or technical computing worker, running on aworkstation170. Thetechnical computing client250 is in communications with thetechnical computing worker270 through anetwork communications channel130 over anetwork140.
• Thetechnical computing client250 can be a technical computing software application that provides a technical computing and graphical modeling environment for generating block diagram models and to define mathematical algorithms for simulating models. Thetechnical computing client250 can be a MATLAB®-based client, which may include all or a portion of the functionality provided by the standalone desktop application of MATLAB®. Additionally, thetechnical computing client250 can be any of the software programs available in the MATLAB® product family. Furthermore, thetechnical computing client250 can be a custom software program or other software that accesses MATLAB® functionality via an interface, such as an application programming interface, or by other means. One ordinarily skilled in the art will appreciate the various combinations of client types that may access the functionality of the system.
• With an application programming interface and/or programming language of thetechnical computing client250, functions can be defined representing a technical computing task to be executed by either a technical computing environment local to theclient computer150, or remote on theworkstation270. The local technical computing environment may be part of thetechnical computing client250, or a technical computing worker running on theclient computer150. The programming language includes mechanisms, described below in more detail, to define a task to be distributed to a technical computing environment and to communicate the task to thetechnical computing worker270 on theworkstation170, or alternatively, on theclient150. For example, thetechnical computing client250 may declare a function to generate a random set of ten numbers and further delegate that thetechnical computing worker270 running on theworkstation170 execute the function. Also, the application programming interface and programming language of the MATLAB®-basedclient250 includes mechanisms, described in more detail below, to receive a result from the execution of technical computing of the task from another technical computing environment. For example, thetechnical computing client250 may declare a variable to hold a result returned from thetechnical computing worker270 performing technical computing of the random generation function.
• The distributed functionality features of the programming languages of the MATLAB®-basedclient250 allows thetechnical computing client250 to use the computing resources that may be available from atechnical computing worker270 on theworkstation170 to perform technical computing of the task. This frees up thetechnical computing client250 to perform other tasks, or theclient computer150 to execute other software applications.
• Thetechnical computing worker270 of thesystem200 can be a technical computing software application that provides a technical computing environment for performing technical computing of tasks, such as those tasks defined or created by thetechnical computing client250. Thetechnical computing worker270 can be a MATLAB®-based worker application, module, service, software component, or a session, which includes support for technical computing of functions defined in the programming language of MATLAB®. A session is an instance of a runningtechnical computing worker270 by which a technical computing client can connect and access its functionality. Thetechnical computing worker270 can include all the functionality and software components of thetechnical computing client250, or it can just include those software components it may need to perform technical computing of tasks it receives for execution. Thetechnical computing worker270 may be configured to and capable of running any of the modules, libraries or software components of the MATLAB® product family. As such, thetechnical computing worker270 may have all or a portion of the software components of MATLAB® installed on theworkstation170, or alternatively, accessible on another system in thenetwork140. Thetechnical computing worker270 has mechanisms, described in detail later, to receive a task distributed from thetechnical computing client250. Thetechnical computing worker270 is capable of performing technical computing of the task as if thetechnical computing client250 was performing the technical computing in its own technical computing environment. Thetechnical computing worker270 also has mechanisms, to return a result generated by the technical computing of the task to thetechnical computing client250.
• Thetechnical computing worker270 can be available on an as needed basis to thetechnical computing client250. When not performing technical computing of tasks from thetechnical computing client250, theworkstation170 of thetechnical computing worker270 can be executing other software programs, or thetechnical computing worker270 can perform technical computing of tasks from other technical computing clients.
• FIG. 2B shows another illustrative embodiment of the MATLAB®-based distributed computing system of an embodiment of the present invention in a multi-tier distributed computer system as depicted inFIG. 2B. The multi-tier distributedsystem205 includes atechnical computing client250 running on aclient computer150 in communications over anetwork communication channel130 to aserver160 on anetwork140. Theserver160 comprises an automatictask distribution mechanism260 and ajob manager265. Thejob manager265 interfaces with the automatictask distribution mechanism260 on theserver160. The automatictask distribution mechanism260 communicates over anetwork communication channel130 on thenetwork140 to thetechnical computing worker270 on theworkstation170.
• The automatictask distribution mechanism260 comprises one or more application software components to provide for the automatic distribution of tasks from thetechnical computing client250 to thetechnical computing worker270. The automatictask distribution mechanism260 allows thetechnical computing client250 to delegate the management of task distribution to the automatictask distribution mechanism260. For example, with the programming language of MATLAB®, a task can be defined and submitted to the automatictask distribution mechanism260 without specifying whichtechnical computing worker270 is to perform the technical computing of the task. Thetechnical computing client250 does not need to know the specifics of thetechnical computing worker270. The technical computing client can define a function to submit the task to the automatictask distribution mechanism260, and get a result of the task from the automatictask distribution mechanism260. As such, the automatic task distribution mechanism provides a level of indirection between thetechnical computing client250 and thetechnical computing worker270.
• This eases the distributed programming and integration burden on thetechnical computing client250. Thetechnical computing client250 does not need to have prior knowledge of the availability of thetechnical computing worker270. For multiple task submissions from thetechnical computing client250, the automatictask distribution mechanism260 can manage and handle the delegations of the tasks to the sametechnical computing worker270, or to other technical computing workers and hold the results of the tasks on behalf of thetechnical computing client250 for retrieval after the completion of technical computing of all the distributed tasks.
• As part of the software components of the MATLAB®-based distributed computing environment, ajob manager module265, or “job manager”, is included as an interface to the task and result management functionality of the automatictask distribution mechanism260. Thejob manager265 can comprise an object-oriented interface to provide control of delegating tasks and obtaining results in the multi-tiered distributedsystem205. Thejob manager265 provides a level of programming and integration abstraction above the details of inter-process communications and workflow between the automatictask distribution mechanism260 and thetechnical computing worker270. Thejob manager265 also provides an interface for managing a group of tasks collectively as a single unit called a job, and on behalf of atechnical computing client250, submitting those tasks making up the job, and obtaining the results of each of the tasks until the job is completed. Alternatively, the automatictask distribution mechanism260 can include the functionality and object-oriented interface of thejob manager265, or the automatictask distribution mechanism260 and thejob manager265 can be combined into a single application, or software component. In an exemplary embodiment, thejob manager265 comprises both the functionality of thejob manager265 and the automatictask distribution mechanism260. One ordinarily skilled in the art will recognize the functions and operations of thejob manager265 and the automatictask distribution mechanism260 can be combined in various software components, applications and interfaces.
• Referring now toFIG. 2C, an exemplary embodiment of the present invention is shown with multipletechnical computing workers270A-270N hosted on a plurality ofworkstations170A-170N. Thetechnical computing client250 may be in communication through thenetwork communication channel130 on thenetwork140 with one, some or all of thetechnical computing workers270A-270N. In a similar manner, the automatictask distribution mechanism260 may be in communication through thenetwork communication channel130 on thenetwork140 with one, some or all of thetechnical computing workers270A-270N. As such, thetechnical computing client250 and/or the automatictask distribution mechanism260 can distribute tasks to multipletechnical computing workers270A-270N to scale the distributed system and increase computation time of tasks. As also shown inFIG. 2C, thetechnical computing workers270A-270B can be hosted on thesame workstation170A, or a singletechnical computing worker270C can have adedicated workstation170B. Alternatively, one or more of thetechnical computing workers270A-270N can be hosted on either theclient150 or theserver160.
• The computing devices (102,102′,102″,102′″) depicted inFIGS. 1A and 1B can be running any operating system such as any of the versions of the Microsoft® Windows operating systems, the different releases of the Unix and Linux operating systems, any version of the MacOS® for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on the computing device and performing the operations described herein. Furthermore, the software components of MATLAB®-based distributed computing environment can be capable of and configured to operate on the operating system that may be running on any of the computing device (e.g.,102,102′,102″,102′″). Additionally, each of theclient150, theserver160 and theworkstation170 can be running the same or different operating systems. For example, theclient150 can running Microsoft® Windows, theserver160 can be running a version of Unix, and the workstation a version of Linux. Or each of theclient150, theserver160 and theworkstation170 can be running Microsoft® Windows. Additionally, the software components of the MATLAB®-based distributed computing environment can be capable of and configured to operate on and take advantage of different processors of any of the computing device (e.g.,102,102′,102″,102′″). For example, the software components of the MATLAB®-based distributed computing environment can run on a 32 bit processor of onecomputing device102 and a 64 bit processor of anothercomputing device102′. In a distributed system, such as the system depicted inFIG. 1B, MATLAB®-based distributed computing application can operate on computing devices (102,102′,102″,102′″) that can be running on different processor architectures in addition to different operating systems. One ordinarily skilled in the art will recognize the various combinations of operating systems and processors that can be running on any of the computing devices (102,102′,102″, and102′″).
• Although the present invention is discussed above in terms of distributing software components of the MATLAB®-based distributed computing application across the computing devices of aclient150,server160 andworkstation170, any other system and/or deployment architecture that combines and/or distributes one or more of thetechnical computing client250,job manager265, automatictask distribution mechanism260 andtechnical computing worker270 across any other computing devices and operating systems available in thenetwork140 may be used. Alternatively, all the software components of the MATLAB®-based distributed computing application can run on asingle computing device102, such as theclient150,server160 or theworkstation170.
• The MATLAB®-based distributed computing application of an embodiment of the present invention provides flexibility in methods of task distribution with multiple modes of operation. InFIGS. 3A,3B and3C, three modes of task distribution of the MATLAB®-based distributed computing environment are shown.FIG. 3A depicts a direct distribution mode,FIG. 3B, an automated distribution mode andFIG. 3C, a batch mode of automated distribution. Additionally,FIG. 3D depicts an exemplary embodiment of the batch mode of automated distribution.
• Thedirect distribution system305 ofFIG. 3A is intended for those users who desire a high level of control over whichtechnical computing worker270A-270N executes a particular task. In brief overview of thedirect distribution system305, thetechnical computing client250 is in communications with a plurality of technical computing workers,270A-270N, each running on theirown workstation170A-170N. In an alternative embodiment, one or more of thesetechnical computing workers270A-270N can be running on the same computing device, e.g.,workstation270A, or on theclient150 or theserver160. Thisdirect distribution system305 allows a task to be sent to a particular technical computing worker, e.g.,technical computing worker270A of a plurality oftechnical computing workers270A-270N. Then, thetechnical computing client250 can continue with other work while the specified technical computing worker, e.g.,technical computing worker270A, is performing technical computing of the submitted task. Some time after submitting the task to thetechnical computing worker270A, thetechnical computing client250 can then obtain the result of the task from thetechnical computing worker270A. Furthermore, eachtechnical computing worker270N can process multiple tasks, e.g., TaskN-M, and for each task produce a result, e.g., ResultN-M. Alternatively, thetechnical computing worker270A may perform technical computing of a task without returning a result, or may return information acknowledging completion of the task. This mode of task distribution is useful for a computer network with a relatively small number of knownworkstations170A-170N andtechnical computing workers270A-270N. A task can be delegated to a specified technical computing worker running270A on aworkstation170A that has a higher speed configuration than theother workstations170B-170N. For example, a longer task could be executed on such aworkstation170A in order to speed the overall computation time.
• As further depicted inFIG. 3A, thetechnical computing client250 of thedirect distribution system305 can submit multiple tasks (e.g., TaskN-M) to each of the multipletechnical computing workers270A-270N. For example, thetechnical computing client250 submitstask1 totechnical computing worker270A, submits task2 totechnical computing worker270B, and submits task N totechnical computing worker270N. Thetechnical computing client250 can submit task1, task2 and taskN-M one immediately after another or within a certain time between each other. As such, thetechnical computing workers270A-270N can be performing technical computing of their respective tasks independently and in parallel to each other. Alternatively, thetechnical computing workers270A-270N may perform technical computing of their respective task while the other technical computing workers are idle.
• In another embodiment, thetechnical computing workers270A-270N may include interfaces and communication channels to interact with each other as depicted by the phantom arrowed lines between thetechnical computing workers270A-270N inFIG. 3A. In such an embodiment,technical computing worker270A may perform a portion of technical computing on task1, and then submit task1, and optionally, any generated result or other data, for further technical computing bytechnical computing worker270B. Also, thetechnical computing worker270A may also submit the result of its technical computing of task1 to thetechnical computing client250, before or after, submitting the task totechnical computing worker270B for further processing.Technical computing worker270B may in turn perform technical computing of task1, and subsequently submit task1 for further processing bytechnical computing worker270N. For additional configurability, thetechnical computing workers270A-270N can obtain information with the task about the identification of othertechnical computing workers270A-270N in the system. This information would be used to communicate and interact with another technical computing worker. Alternatively, atechnical computing worker270A may find anothertechnical computing worker270B-270N by making a function or system call, or a method call to a service provider on thenetwork140. In such a configuration,technical computing workers270A-270N can either execute tasks independently and in parallel to each other, or also execute tasks serially and subsequent to each other.
• Referring now toFIG. 3B, the automated task distribution mode embodied insystem310 is intended to provide a configuration where the user does not want to control whichtechnical computing worker270A-270N executes a particular task. In brief overview of the automated distribution mode ofsystem310, atechnical computing client250 is in communication with the automatictask distribution mechanism260 running on theserver160. The automatictask distribution mechanism260 is in communications with a plurality oftechnical computing workers270A-270N. Under this mode of operation, thetechnical computing client250 is not required to have any specific knowledge of thetechnical computing workers270A-270N, e.g., the name of the workstation running atechnical computing worker270A-270N, or the availability of thetechnical computing worker270A-270N to perform technical computing of a task. In alternative embodiments, it may have prior knowledge of all or a portion of thetechnical computing workers270A-270N available on the network. Even with knowledge of the name or availability oftechnical computing workers270A-270N on thenetwork140, thetechnical computing client250 can choose not to specify the name of a particular technical computing worker to perform the task, and let the automated distribution mechanism distribute the task to any availabletechnical computing worker270A-270N.
• InFIG. 3B, thetechnical computing client250 submits one or more tasks (Task1-TaskN-M) to the automatictask distribution mechanism260. These tasks can be submitted sequentially or in an order and frequency as specified by thetechnical computing client250. The automatictask distribution mechanism260 obtains the tasks (Task1-TaskN-M) to make then available for distribution to any of thetechnical computing workers270A-270N. Atechnical computing worker270A-270N takes a task from the automatictask distribution mechanism260 for technical computing of the task, computes a result for the task and provides the result to the automatictask distribution mechanism260. For example,technical computing worker270A takestask1 from the automatictask distribution mechanism260, computes a result,Result1, fortask1, and submitsResult1 to the automatictask distribution mechanism260. The automatictask distribution mechanism260 makes the results (Result1-ResultN-M) available to thetechnical computing client250 as they get submitted from thetechnical computing worker270A-270N generating and submitting the respective result. At a time or method determined by thetechnical computing client250, thetechnical computing client250 obtains the results of the computed tasks from the automatictask distribution mechanism260. For example, thetechnical computing client250 may obtain all the results (Result1-ResultN-M) at the same time after all the results have been computed, or each result may be obtained after it becomes available in the automatictask distribution mechanism260. Accordingly, thetechnical computing client250 can determine the order and frequency of obtaining one or more of the results. As with the direct distribution mode, thetechnical computing workers270A-270N can also communicate and interact with each other, as depicted by the phantom arrowed lines between thetechnical computing workers270A-270N inFIG. 3B, to execute tasks both serially and in parallel by submitting a task to anothertechnical computing worker270A-270N.
• The batch mode of automated task distribution embodied insystem315 ofFIG. 3C is intended to provide a configuration where the user can specify a group of related tasks as a job and provide the batch of tasks, or the job, to the automatictask distribution mechanism260. In brief overview of the batch mode of theautomatic distribution system315, atechnical computing client250 is in communication with thejob manager265 on theserver160. Thejob manager265 interfaces and communicates with the automatictask distribution mechanism260 running on thesame server160. Each of thetechnical computing workers270A-270N is in communication with the automatictask distribution mechanism260. Ajob manager265 interfaces with and is associated with one automatictask distribution mechanism260. Alternatively, thejob manager265 and the automatic task distribution mechanism could be ondifferent servers160. Additionally, a plurality of job managers and automatic task distribution mechanisms could be running on asingle server160 or each on their own servers. Each of the plurality of job managers interface with and are associated with one of the plurality of automatic distribution mechanisms. This allows the distributed system to scale the number of instances of thejob manager265 and theautomatic distribution mechanism260 to handle additional multipletechnical computing clients250 distributing tasks.
• In batch mode as depicted inFIG. 3C, thetechnical computing client250 defines the job. Thetechnical computing client250 has a programming language environment by which it can declare tasks, declare a job and associate the tasks with the job. Instead of submitting each task separately as depicted inFIG. 3B, thetechnical computing client250 submits the job containing all the associated tasks to thejob manager265. Thejob manager265 is a software component that provides an object-oriented interface to the automatictask distribution mechanism260. Thejob manager265 obtains the tasks from the job and provides the tasks to the automatictask distribution mechanism260 fortechnical computing workers270A-270N to take and compute results. For example,technical computing client250 defines a job, Job1, with a set of three tasks: Task1, Task2 and TaskN-M. Thetechnical computing client250 then submits Job1 to thejob manager265. Thejob manager265 obtains Job1 and obtains each of the tasks, Task1-TaskN-M fromJob1. Then, according to the configured logic of thejob manager265, described in more detail below, thejob manager265 submits each of the tasks to the automatictask distribution mechanism260 for technical computing by atechnical computing worker270A-270N.Technical computing worker270A may take Task1 from the automatictask distribution mechanism260, compute a Result1 for Task1 and provide the Result1 to the automatictask distribution mechanism260.Technical computing worker270B andtechnical computing worker270N, in a similar fashion, compute and provide results for Task2 and TaskN-M respectively. Thejob manager265 then obtains the set of results for the completed job of Job1 and provides the results of each of the tasks to thetechnical computing client250.
• Thejob manager265 further comprises aqueue267 for arranging and handling submitted jobs. For example, thejob manager265 may handle jobs in a first-in first-out (FIFO) manner. In this case, thejob manager265 does not process the next job until all the tasks from the current job have been processed by the automatictask distribution mechanism260. Additionally, thejob manager265 using thequeue267 supports handling multiple job submissions and task distribution from multipletechnical computing clients250. If a firsttechnical computing client250 submits a job, Job1, thejob manager265 places that job first in thequeue267. If a second technical computing client submits a second Job, for example, Job2, the job manager places the job in the queue behind the Job1 from the first client. In this manner, alltechnical computing clients250 accessing the services of thejob manager265 get serviced for task distribution. One ordinarily skilled in the art will recognize that thejob manager265 could implement a variety of algorithms for processing jobs in ajob queue267 and for handling multipletechnical computing clients250. For example, a user may be able to specify a priority level for a specified job, or the logic of thejob manager265 may make task distributing and processing decisions based on the configuration and availability oftechnical computing workers270A-270B to determine a preferred or optimal selection of technical computing of jobs and tasks.
• As with the other distribution modes ofFIG. 3A andFIG. 3B, thetechnical computing workers270A-270N in batch mode can also communicate and interact with each other as shown by the phantom arrowed lines betweentechnical computing workers270A-270N inFIG. 3C. This allows thetechnical computing workers270A-270N to execute tasks both serially and in parallel by submitting a task to another technical computing worker. As part of the information associated with the task obtained by a technical computing worker or by other means, such as a system or function call, or a method call to a service, atechnical computing worker270A can obtain information about the othertechnical computing workers270B-270N assigned to or working on tasks associated with a specific job, or available on thenetwork140.
• The exemplary embodiment of the batch mode of automatedtask distribution system320 ofFIG. 3D depicts a configuration where thejob manager265 contains the automatictask distribution mechanism260. In brief overview ofsystem320, atechnical computing client250 is in communication with thejob manager265 on theserver160. Thejob manager265 comprises atask distribution mechanism260 running as part of thejob manager265 on thesame server160. Thejob manager265 further comprises aqueue267 for arranging and handling submitted jobs. Thetechnical computing workers270A-270N are in communication with thejob manager265 to receive tasks from the automatictask distribution mechanism260 of thejob manager265.
• In batch mode operation as depicted inFIG. 3D, thetechnical computing client250 defines the job comprised of related tasks. Instead of submitting each task separately as depicted inFIG. 3B, thetechnical computing client250 submits the job containing all the related tasks to thejob manager265. Thejob manager265 obtains the tasks from the job and submits the tasks, via an automatictask distribution mechanism260, to thetechnical computing workers270A-270N to perform technical computing. For example,technical computing client250 defines a job, Job1, with a set of three tasks: Task1, Task2 and TaskN-M. Thetechnical computing client250 then submits Job1 to thejob manager265. Thejob manager265 obtains Job1 and obtains each of the tasks, Task1-TaskN-M, fromJob1. Then, the automatictask distribution mechanism260 of thejob manager265 submits each of the tasks to atechnical computing worker270A-270N for technical computing. For example, thejob manager265 may submitTask1 totechnical computing worker270A to compute and produce a Result1 for Task1.Technical computing worker270A provides the Result1 to thejob manager265. In a similar fashion, thejob manager265 may submit Task2 and TaskN-M totechnical computing worker270B andtechnical computing worker270N with eachtechnical computing worker270A and270B providing the results for Task2 and TaskN-M respectively to thejob manager265. When all the results from each of the tasks of Job1 are received, thejob manager265 then provides the results of each of the tasks ofJob1 to thetechnical computing client250.
• In the batch mode of operation of depicted inFIGS. 3C and 3D, thejob manager265 or automatictask distribution mechanism260 can be configured to define the minimum and maximum numbers oftechnical computing workers270A-270N to perform the tasks associated with a job. This feature can be configured on a job by job basis. Alternatively, it may be configured for a portion or all of the jobs. The configuration of these settings can be facilitated through parameters associated with a submitted job, such as in one or more properties of a job object, or in one or more fields of a data structure representing a job. Alternatively, these settings may be facilitated through any interface of thejob manager265 or automatictask distribution mechanism260, such as in a configuration file, graphical user interface, command or message or any other means by which values for these settings may be set.
• The system (e.g.315 or320) can compare the number oftechnical computing workers270A-270N registered, or otherwise available, with thejob manager265 or automatictask distribution mechanism260 against the configured setting of the minimum number of technical computing workers parameter. The system may not start a job unless there is a minimum number oftechnical computing workers270A-270N registered or available to work on the job. In a similar manner, the system can check the number of available or registeredtechnical computing workers270A-270N against the setting of the maximum number of technical computing workers parameter. As the system distributes tasks of a job, it can make sure not to distribute tasks to more than the defined number oftechnical computing workers270A-270N. In some embodiments, the minimum number of technical computing workers will be set to a value equal to the setting of the maximum number of technical computing workers. In such a case, the system may only start the job if the minimum number oftechnical computing workers270A-270A are available or registered to start the job, and may not use any moretechnical computing workers270A-270N than the minimum setting. This is useful for cases where the user wants to configure a job to have each task be assigned to and run on separatetechnical computing workers270A-270N. For example, a job may have 5 tasks and the minimum and maximum technical computing worker settings may be set to 5.
• Additionally, in any of the embodiments depicted inFIGS. 3A-3D, the system can determine or select thetechnical computer worker270A-270N to work on a task by operational and/or performance characteristics of thetechnical computing worker270A-270N and/orworkstation170A-170N. For example, atechnical computing worker270A may work on a task based on the version of the MATLAB®-based distributed computing application that is installed on theworkstation170A or that thetechnical computing worker270A is capable of running.
• Additionally, thetechnical computing worker270A-270N andworkstation170A-170N may have a specification or profile, such as a benchmark comparison results file, which provides a description of any operational and performance characteristics of the version of the MATLAB®-based distributed computing application running on thatspecific computing device102 of theworkstation170A. This profile can be in comparison to known benchmarks of operational and performance characteristics of the MATLAB®-based distributed computing application running on certain computing devices (102,102′,102″,102′″), with specified versions of the MATLAB®-based distributed computing application, operating systems and other related software, or any other system component or attribute that may impact the operation or performance of the MATLAB®-based distributed computing application. This profile may be described in a file accessible over the network or retrievable through an interface mechanism of thetechnical computing worker270A-270N. Furthermore, the system may determine thetechnical computing worker270A-270N to work on a task by any configuration or properties set on thetechnical computing worker270A-270N orworkstation170A-170N. For determining atechnical computing worker270A-270N to work on a task, the system may discover any configuration, properties, and operational and performance characteristics of the MATLAB®-based distributed computing application of atechnical computing worker270A-270N running on aworkstation170A-170N through any interface of thetechnical computing worker270A-N orworkstation170A-170N, such as, for example, in a file, graphical user interface, command or message.
• The MATLAB®-based distributed computing application of an embodiment of the present invention also provides additional flexibility in that the multiple modes of task distribution can be performed concurrently in the distributed system.FIG. 4 is an illustrative embodiment of the present invention showing the distributed application performing, concurrently, the combination of the modes of operation depicted inFIGS. 3A-3C. Additionally, the distributedsystem400 is depicted supportingmultiple clients250A-250N communicating withmultiple job managers265A-265N and multiple automatictask distribution mechanisms260A-260N. With these multiple modes of operation, anytechnical computing client250A-250N can distribute tasks directly to atechnical computing worker270A-270N, submit tasks to the automatictask distribution mechanism260, or submit a job to thejob manager265. In the depicted multi-client distributedsystem400, a plurality oftechnical computing clients250A-250N are in communication with one ormore job managers265A-265N. Thejob manager265A can be a separate component interfacing to the automatictask distribution mechanism260A, or thejob manager265N can be a single application comprising the functionality of the automatictask distribution mechanism260N. The one or moretechnical computing workers270A-270B are in communication with the one ormore job managers265N or the one or more automatictask distribution mechanisms260A. The distributed architecture of the present invention allows for a scalable and flexible distributed technical computing environment supporting a variety of deployments and network topologies.
• For example, as shown inFIG. 4, atechnical computing client250A can operate in both the direct distribution mode and the batch automated distribution mode. As such,technical computing client250A can submit a task to and receive a result from the automatictask distribution mechanism260A without using thejob manager265A. In another instance,technical computing client250A can submit a job, Job1, to thejob manager265A for task distribution by the automatictask distribution mechanism260A to receive results from the job, such as Job1Results. In another example ofFIG. 4,technical computing client250B can operate in batch automated distribution mode but submit jobs separately to afirst job manager265A running on afirst server160A and asecond job manager265N running on asecond server160N. In yet another example,technical computing client250N operates in both the automated distribution and direct distribution modes.Technical computing client250N submits a task, Task2, to automatictask distribution mechanism260N and receives a result, Task2Result, from computing by atechnical computing worker270A-270N assigned by thesystem400.Technical computing client250N also directly submits a task totechnical computing worker270N and receives a computed result directly from thetechnical computing worker270N. One ordinarily skilled in the art will appreciate the various combinations of deployments that can occur with such a distributedsystem400 with multiple modes of operation. As such, the present invention offers scalability and flexibility for distributed processing of complex technical computing requirements.
• In another aspect, the present invention relates to methods for distributing tasks totechnical computing workers270A-270N for processing, either directly, or indirectly and automatically, as described above in reference to the embodiments depicted inFIGS. 3A-3C.FIGS. 5A,5B and5C each show a flow diagram of the methods of the three modes of task distribution of the MATLAB®-based distributed computing application.FIG. 5A depicts the method of direct distribution,FIG. 5B, the method of an automated distribution, andFIG. 5C, a batch mode method of automated distribution.
• Referring now toFIG. 5A, one embodiment of themethod500 to distribute a task from atechnical computing client250 to atechnical computing worker270 is illustrated.Method500 is practiced with the direct distribution embodiment of the invention depicted inFIG. 3A. Thetechnical computing client250 defines a task comprising an operation for technical computing (step502). The task defines a function, command or operation, such as may be available in the programming language of MATLAB®, and the number of arguments and input data of the arguments. Thetechnical computing client250 then submits the task (step504) to thetechnical computing worker270. Thetechnical computing worker270 receives the task (step506) and performs the requested technical computing as defined by the task (step508). In performing the technical computing on the task, an associated result may be generated (step510). In alternative embodiments, either no result is generated, or no result is required to be returned to thetechnical computing client250. After generating the result from computing the task, thetechnical computing worker270 provides the result (step512) to thetechnical computing client250, and thetechnical computing client250 obtains the result from the technical computing worker270 (step514).
• Referring now toFIGS. 5B, an embodiment of themethod525 to distribute a task from atechnical computing client250 to atechnical computing worker270 in automated task distribution mode is illustrated.Method525 is practiced with the automatic task distribution embodiment of the invention depicted inFIG. 3B. Atechnical computing worker270 registers to receive notification of one or more tasks (step527) becoming available, or appearing, in the automatictask distribution mechanism260. Thetechnical computing client250 defines a task comprising an operation for technical computing (step502). Thetechnical computing client250 then submits the task (step530) to the automatictask distribution mechanism260. The automatictask distribution mechanism260 receives the task and makes the task available for distribution (step532) to atechnical computing worker270. The technical computing client registers (step534) with the automatictask distribution mechanism260 to receive notification when a result associated with the task submitted instep530 is available, or appears, in the automatictask distribution mechanism260. The automatictask distribution mechanism260 registers thetechnical computing client250 for notification when the result appears (step536). The automatictask distribution mechanism260 provides notification (step538) to thetechnical computing worker260 of the availability of the task. In response to receiving the notification (step540), the technical computing worker obtains (step544) the task provided (step540) from the automatictask distribution mechanism260. Thetechnical computing worker270 performs the requested technical computing on the function or command as defined by the task (step508). In performing the technical computing on the task, an associated result may be generated (step510). In alternative embodiments, either no result is generated or the result is not required to be returned to thetechnical computing client250. After generating the result from computing the task (step510), thetechnical computing worker270 provides the result (step512) to the automatictask distribution mechanism260. After obtaining the result from the technical computing worker250 (step550), the automatictask distribution mechanism260 notifies (step552) thetechnical computing client250 that the result is available. Thetechnical computing client250 obtains (step556) the result provided (step558) by the automatictask distribution mechanism260.
• Referring now toFIGS. 5C and 5D, one embodiment of themethod560 to distribute a task from atechnical computing client250 to atechnical computing worker270 in a batch mode of operation is illustrated.Method560 is practiced with the batch mode of the automatic task distribution system (e.g.315 or320). Atechnical computing worker270 registers to receive notification of one or more tasks (step527) becoming available, or appearing, in the automatictask distribution mechanism260. In an exemplary embodiment, the technical computing worker registers to receive a task from thejob manager265 or automatictask distribution mechanism260 as notification to perform computing on the task. Thetechnical computing client250 defines one or mores tasks (step562), with one or more of the tasks comprising an operation or function for technical computing. Thetechnical computing client250 groups one or more tasks of the tasks into a job (step564). Thetechnical computing client250 then submits the job (step566) to thejob manager265. Thejob manager265 obtains the job (step568) from thetechnical computing client250 and provides the one or more tasks of the job (step570) to the automatictask distribution mechanism260, which makes the one or more tasks available for distribution (step572) to one or moretechnical computing workers270A-270N. In an exemplary embodiment, thejob manager265 or the automatictask distribution mechanism260 may submit the one or more tasks to the one or moretechnical computing workers270A-270N. In another embodiment, thetechnical computing worker270 may take the task from thejob manager265 or the automatictask distribution mechanism260.
• Thetechnical computing client250 registers (step574) a callback function with thejob manager265. Thetechnical computing client250 may setup and/or register other callback functions based on changes in the state of processing of a task or job, or changes in the state of the job manager, or other events available to trigger the calling of a function. Thejob manager265 calls this function when the job is completed, i.e., when each of the one or more tasks of the job have been completed. In turn, thejob manager265 may register (step576) with the automatictask distribution mechanism260 to receive notification of the results of the submitted tasks appearing in the automatictask distribution mechanism260, or being received from thetechnical computing worker270A-270N. In one embodiment, the automatictask distribution mechanism260 registers the notification request of the job manager (step578). Then, the automatictask distribution mechanism260 provides notification to thetechnical computing worker270 of the availability of the task (step538). In an exemplary embodiment, the task is sent, by thejob manager265 to thetechnical computing worker270 as notification to perform the task. In response to receiving the notification or the task (step540), thetechnical computing worker270 obtains (step542) the task provided (step540) from the automatictask distribution mechanism260 or thejob manager265. Thetechnical computing worker270 performs the requested technical computing on the operation as defined by the task (step508). In performing the technical computing on the task, an associated result may be generated (step510). In alternative embodiments, either no result is generated or the result is not required to be returned to thetechnical computing client250. After generating the result from computing the task (step510), thetechnical computing worker270 provides the result (step510) to the automatictask distribution mechanism260 or thejob manager265. After obtaining the result from the technical computing worker250 (step550), the automatictask distribution mechanism260 notifies (step587) thejob manager265 that the result is available. In an exemplary embodiment, thejob manager265 receives the results from thetechnical computing worker270. In response to receiving the notification or the result (step589), thejob manager265 obtains the result (step591) provided by (step593) the automatictask distribution mechanism260. If thejob manager265 received the last result of the job, thejob manager265 will notify thetechnical computing client250 that the job is completed via the registered callback function (step595). After triggering the completed job callback function (step597), thetechnical computing client250 obtains (step598) the result provided (step599) by thejob manager265.
• With the methods of task distribution described above (methods500,525, and560) in view of the embodiment of the concurrent multiple distribution modes of operation depicted insystem400 ofFIG. 4, one ordinarily skilled in the art will recognize the application of the above methods to the multiple modes of operation for eachtechnical computing client250A-250N inFIG. 4.
• FIG. 6A shows the details of one embodiment of the automation features of atechnical computing client250 andtechnical computing worker270 distributing tasks and results with the automatictask distribution mechanism260. The automatictask distribution mechanism260 may be object-oriented and comprise anobject exchange repository662, such as Javaspace, a Sun Microsystems, Inc. technology for distributed application development built using Jini network technology also from Sun Microsystems, Inc.
• The JavaSpace technology views an application as a collection of processes cooperating via a flow of objects into and out of anobject exchange repository662, known as a space. It does not rely on passing messages directly between processes or invoking methods directly on remote objects. A key feature is that spaces are shared. Many remote processes, such as technical computing workers and job managers of the present invention, can interact with the network accessible object storage of a space. Spaces are also persistent and therefore, provide reliable storage. Spaces are also associative in that objects in the space can be located by associative lookup rather than by memory location or identifier, e.g., in a shared memory solution. Additionally, a space has a few key operations to perform on the object repository to handle the exchanging of objects. A write operation writes an object, such as a task object, to the space. A take operation takes an object, such as result object, from the space. A take is the equivalent of a read and removes the object from the space. A read operation obtains a copy of the object from the space and leaves the object intact in the space. Other operations allow remote processes, such as technical computing workers, technical computing clients and job managers to register for event notification when a certain object appears in the space. An object appears in the space when a process writes the object to the space. The remote process listens for the appearance of objects in the space and the space notifies the registered remote process when the object appears.
• In an alternative embodiment of the present invention, an object exchange repository such as one implemented with JavaSpace technology is used to provide a level of indirection between thetechnical computing client250 and thetechnical computing worker270 with regards to task and result objects. By the automatic communication features described above, thetechnical computing client250 does not need to specify a namedtechnical computing worker270 to perform technical computing. The automatictask distribution mechanism260 comprising theobject exchange repository662 handles task distribution totechnical computing workers270A-270N registered with the automatictask distribution mechanism260. To distribute tasks and results, thetechnical computing client250 andtechnical computing worker270 read and write task and result objects to theobject exchange repository662.
• Referring now toFIG. 6A, atechnical computing client250 executes a write transaction to write a task object to theobject exchange repository662 of the automatictask distribution mechanism260. The task object defines a task for technical computing by atechnical computing worker270 who obtains the task object from theobject exchange repository662. Thetechnical computing client250 registers with theobject exchange repository662 to be notified when a result object associated with the submitted task object is available in theobject exchange repository662. In this way, thetechnical computing client250 can listen for the appearance of results for tasks submitted for technical computing processing. Atechnical computing worker270 registers with theobject exchange repository662 to be notified when a task object appears in theobject exchange repository662. After thetechnical computing client250 writes the task object, theobject exchange repository662 sends a notification to thetechnical computing worker270 informing of the task object being available in theobject exchange repository662. Thetechnical computing worker270, in response to the notification, performs a take operation on theobject exchange repository662 to retrieve the submitted task object. The take operation removes the task from theobject exchange repository662. In the alternative, a read operation can be performed to get a copy of the task object without removing it from theobject exchange repository662.
• Thetechnical computing work270 obtains the name and arguments of the function to compute from the data structure of the task object. Then thetechnical computing worker270 provides the result from the computation by performing a write operation to write a result object to theobject exchange repository662. The result object defines within its data structure a result of the computation of the function defined in the task object and performed by thetechnical computing worker270. The write of the result object to theobject exchange repository662 triggers the notification event registered by thetechnical computing client250. Thetechnical computing client250 listening for the result to appear in theobject exchange repository662, in response to the notification, performs a take operation, or alternatively a read operation, to obtain the result object associated with the submitted task. Thetechnical computing client250 then obtains the result information defined within the data structure of the retrieved result object.
• FIG. 6B depicts the operations of the automatictask distribution mechanism260 interfacing with ajob manager265. In this embodiment, thejob manager265 is a software component providing a front-end interface to the automatictask distribution mechanism260, and in this exemplary embodiment, the JavaSpaceobject exchange repository662. Thejob manager265 supports the batch mode of automatic task distribution operation of the invention. Under batch processing, tasks are grouped into a job in thetechnical computing client250 and then the job is submitted to thejob manager265 for task distribution and task processing by atechnical computing worker270. When thejob manager265 receives a job from one or moretechnical computing clients250A-250N, thejob manager265 places the job into a position in ajob queue267. Thejob queue267 is a data structure for holding and arranging jobs, and maintaining the state and other attributes about the job while the job is being processed. Thejob manager265 handles jobs in a first-in first-out (FIFO) manner and manages thejob queue267 to first take out the job that was first received by thejob manager265 and placed into thejob queue267. For example, thejob queue267 depicted inFIG. 6B is holding the jobs of job1, job2 through jobn. Job1 is the first submitted job to thejob manager265 and is positioned at the top of thejob queue267. Job2 through JobN are the next subsequent jobs in thejob queue267 in order of a FIFO queuing system. While Job1 is being processed, thejob manager265 does not start to process the next job, Job2, until there are no tasks from the Job1 remaining to be processed in theobject exchange repository662. One ordinarily skilled in the art will appreciate the variations of job management implementations that may be accomplished using a job queue with different queuing and priority mechanisms.
• Still referring toFIG. 6B, thetechnical computing client250 submits a job to thejob manager265 and specifies a callback function with thejob manager265. Thejob manager265 is to call the callback function when the job is completed. The job manager receives the job, e.g., job1, and places the job into ajob queue267. Thejob manager265 then obtains the one or more tasks from the first job submitted to the job queue. In the embodiment of a JavaSpace implementation of theobject exchange repository662, thejob manager265 writes the task object to theobject exchange repository662. Thejob manager265 registers with theobject exchange repository662 to receive a notification when a result object associated with the task appears in theobject exchange repository662, also known as a space. Thejob manager265 listens and waits for the result to appear in theobject exchange repository662.
• Atechnical computing worker270 registers with theobject exchange repository662 to receive a notification when a task object appears in theobject exchange repository662. Then thetechnical computing worker270 listens for the appearance of task objects. When the task is submitted to theobject exchange repository662 by thejob manager265, thetechnical computing worker270 receives a notification and takes the task from theobject exchange repository662 by performing a take operation. Thetechnical computing worker270 obtains the function to be executed from the definition of the function in data structure of the task object, performs the function and generates a result of the function for the task. Then thetechnical computing worker270 submits a result object representing a result of the task to the object exchange repository by performing a write operation. Thejob manager265 waiting for the result to appear in theobject exchange repository662 receives a notification from theobject exchange repository662 that the result is available. Thejob manager265 checks to see if this is the last result to be obtained from theobject exchange repository662 for the job currently being processed. If the result is the last result, thejob manager265 then notifies thetechnical computing client250 that the job is completed by calling the registered callback function. In response to executing the callback function, thetechnical computing client250 then interfaces with thejob manager265 to retrieve the results from thejob manager265, which thejob manager265 retrieves from theobject exchange repository662 by performing a take operation.
• FIG. 6C depicts an exemplary embodiment of details of the batch mode of operation of the present invention using a database rather than an object exchange repository. In this embodiment, thejob manager265 includes the functionality of the automatictask distribution mechanism260. In brief overview, thetechnical computing client250 is in communication with thejob manager265, which is in communication with thetechnical computing worker270. The job manager comprises ajob queue267, an automatictask distribution mechanism260, ajob runner667, aworker pool668 and adatabase669. Any of these components of thejob manager265 can be a separate library, interface, software component or application. In an exemplary embodiment, these components can be running in their own processing thread to provide multi-tasking capabilities.
• Theworker pool668 contains a list oftechnical computing workers270A-270N that are available to work on a task. Thesetechnical computing workers270A-270N may on startup register with ajob manager265. The name of thejob manager265 thetechnical computing worker270A-270N is associated with may be configurable by an interface of thetechnical computing worker270A-270N, or by a command line startup parameter, or an external configuration or registration file. Theworker pool668 may keep a list of “good”technical computing workers270A-270N, or those workers to which thejob manager265 can communicate with and can determine has such a status to be available for processing tasks. Thejob manager265 can update theworker pool667 by going through the list oftechnical computing workers270A-270N registered in theworker pool667 and sending communications to each of thetechnical computing workers270A-270N to determine their status and if they are available. Accordingly, theworker pool667 can be updated to determine the current set oftechnical computing workers667 available, or otherwise able to receive tasks from thejob manager265.
• Thejob runner667 is responsible for determining the next task to work on and for submitting the task to atechnical computing worker270A-270N. Thejob runner667 works with thejob queue267 and takes the next task for processing from a job in thejob queue267. Thejob runner667 obtains from the worker pool668 a name of or reference to atechnical computing worker270A-270N and submits the task for processing to the obtainedtechnical computing worker270A-270N. Thejob runner667 may be configured to have business rule logic to determine the next task to take from the job queue either in a FIFO manner supported by thejob queue267 or any other manner based on priority, availability, task and job option settings, user configuration, etc. Thejob runner667 in conjunction with theworker pool668 and thejob queue267 can form a portion of or all of the functionality of the automatictask distribution mechanism260. Thejob runner667 can have such logic to determine from theworker pool668 whichtechnical computing worker270A-270N should be assigned and sent a task from thejob queue267. Alternatively, a separate automatictask distribution mechanism260 can be responsible for determining thetechnical computing worker270A-270N to be assigned a task and to send the task to the assignedtechnical computing worker270A-270N. In any of these embodiments, thetechnical computing worker250 does not need to know the identity, such as via a hostname or an internet protocol address, of thetechnical computing worker270A-270N assigned to perform technical computing on a task.
• Thejob manager265 also has adatabase669 for storing and retrieving job manager, job and task objects and data, or other objects and data to support the operations described herein. For example, jobs in thejob queue267, the list of workers of theworker pool668, the tasks of any jobs in thejob queue267, the properties of any of the task, job or job manager objects may be stored in thedatabase669. Thedatabase669 can be a relational database, or an object-oriented database, such as database software or applications from Oracle® or SQL Server from Microsoft®, or any other database capable of storing the type of data and objects supporting the operations described herein. Thedatabase669 can be an inprocess database669 of thejob manager265 or it can be aremote database669 available on anothercomputing device102′ or anotherserver260′. Furthermore, each instance of thejob manager265A-265N could use a different database and operating system than other instances of thejob manager265A-265N, or be using a local database while anotherjob manager265A-265N uses a remote database on anotherserver160′. One ordinarily skilled in the art will appreciate the various deployments of local or remote database access for each of the one ormore job managers265A-265N.
• Thejob manager265 can be configured to execute certain functions based on changes of the state of a job in thequeue267. For example, thetechnical computing client250 can setup functions to be called when a job is created in ajob queue267, when the job is queued, when a job is running or when a job is finished. Thejob manager265 is to call these functions when the appropriate change in the state of job occurs. In a similar manner, the task and job can be configured to call specified functions based on changes in state of the task or job. For example, a job may be configured to call a function when a job is added to the queue, when a task is created, when a task is completed, or when a task starts running. A task may be configured to call a function when the task is started, or running.
• Referring still toFIG. 6C, thetechnical computing client250 submits a job, Job1, comprised of one or more tasks, such asTask1 and Task2, to thejob manager265. The job manager receives the job, e.g., job1, and places the job into ajob queue267. Thejob runner667 then obtains the one or more tasks from the first job submitted to thejob queue267. Atechnical computing worker270 registers with thejob manager265 and is listed in theworker pool668 of thejob manager265. From theworker pool668, thejob runner667 determines atechnical computing worker270A-270N to submit the task for processing. Thetechnical computing worker270A-270N obtains the function to be executed from the definition of the function in data structure of the task object, performs the function and generates a result of the function for the task. Then thetechnical computing worker270 updates the task object to provide a result of the task. For example, the task object may have a field representing the output arguments from the execution of the function defined by the task. The output arguments may contain one or more arrays of data as allowed by the programming language of MATLAB®. Additionally, the task object may contain an error field to which thetechnical computing worker270A-270N updated to indicate any error conditions in performing the task or executing the function of the task. Thejob manager265 checks to see if this is the last result to be obtained from atechnical computing worker270A-270N for the job currently being processed. If the result is the last result, thejob manager265 can provide the set of task results for the completed job to thetechnical computing client250.
• Although the invention is generally discussed in terms of ajob manager265, automatictask distribution mechanism260 andtechnical computing worker250 as distributed software components available on various computing devices in the network, these software components can be operated as services in a service oriented distributed architecture. One embodiment of a service oriented technology approach is the use of Jini network technology from Sun Microsystems, Inc. Jini network technology, which includes JavaSpaces Technology and Jini extensible remote invocation, is an open architecture that enables the creation of network-centric services. Jini technology provides a method of distributed computing by having services advertise the availability of their provided service over a network for others to discover. Clients and other software components can discover the advertised services and then make remote method calls to the discovered services to access the functionality provided by the service. As such, the software components of the MATLAB®-based distributed computing application can be implemented as services which can be discovered and looked-up via advertising.
• Referring now toFIG. 7, an exemplary embodiment of the invention is shown implementing a service oriented approach with Jini network technology. In broad overview of thesystem700, thetechnical computing client250,technical computing workers270A-270N,job managers265A-265N, automatictask distribution mechanisms260A-260N are in communication over thenetwork140 vianetwork communication channels130. Additionally there is anetwork server760 in communication with thenetwork140 through thenetwork communication channel130. Thenetwork server760 hosts a code base server710. In an exemplary embodiment, the code base server710 is an ftp server. In other embodiments, the code base server710 is a web server, such as Java web server, or an http server. The code base server710 is capable of and configured to upload files, including class or interface files. In an exemplary embodiment, the code base server710 may upload JAR files. The code base server710 may be available on thenetwork140 to Jini based services to obtain class files as a service on thenetwork140 may need, or it may be available to atechnical computing client250 to determine the interface to a service on thenetwork140.
• In support of implementing software components of the present invention as Jini services, one or more of the following Jini services are available on thenetwork server760 on the network140:Reggie718,Mahalo716,Fiddler714 andNorm712. These services are part of the Sun Technology Jini network technology implementation.Reggie718 is a Jini service that provides service registration and discovery. This allows clients of a service to find the service on thenetwork140 without knowing the name of the computing device the service is running on.Mahalo716 is a transaction manager service that provides fault tolerant transactions between services and clients of the service accessing the service.Fiddler714 is a lookup discovery service. A Jini based service needs to register itself with an instance of Reggie in order to be discoverable on thenetwork140. The lookup discovery service ofFiddler714 allows the service to find new Reggie services and register with them while inactive.Norm712 is a lease renewal service. Services registered with Reggie are leased. When the lease on a registration expires, the service becomes unavailable from the instance of Reggie. Norm allows a Jini service to keep leases from expiring while the service is inactive. The services of Reggie, Mahalo, Fiddler and Norm can be run on anycomputing device102 on thenetwork140 capable of running these services and can be run on a single java virtual machine (JVM).
• Referring again toFIG. 7, thetechnical computing workers270A-270N, which provide MATLAB® sessions, are made available as Jini Services to support the direct task distribution mode of operation of the invention. Thetechnical computing workers270A-270N register with a lookup service such asReggie718. This allows thetechnical computing workers270A-270N to be discoverable on thenetwork140 by atechnical computing client250 without thetechnical computing client250 knowing information like the host name of theworkstations170A-170N thetechnical computing workers270A-270N are running on, or the port number to which a specifictechnical computing worker270A-270N service is listening on, or a worker name associated with atechnical computing worker270A-270N.
• Thetechnical computing workers270A-270N also support service activation with anactivation daemon740A-740N software component. Activation allows a technicalcomputing worker service270A-270N to register with anactivation daemon740A-740B to exit and become inactive, but still be available to atechnical computing client250. In all three distribution modes of operation as embodied inFIGS. 3A-3C, the MATLAB®-basedtechnical computing workers270A-270N can be activated by anactivation daemon740A-740N. This means that anactivation daemon740A-740N starts and stops thetechnical computing worker270A-270N. For example, thetechnical computing worker270A service registers with theactivation daemon740A onworkstation170A. Thetechnical computing worker270A includes the activation states of active, inactive and destroyed. In the active state, thetechnical computing worker270A is started and is available for remote method calls from atechnical computing client250. The starting of the service and its availability for remote method calls, or an instance of a running of the service, may be referred to a session. In the inactive state, thetechnical computing client250 is not started, but is still available for remote method calls from atechnical computing client250. If a remote method call to the technicalcomputing worker service270A is made by thetechnical computing client250, the technicalcomputing worker service270A will be started by theactivation daemon740A, and the method call will be executed by the technicalcomputing worker service270A. In the destroyed state, the technicalcomputing worker service270A is not running and is not registered with theactivation daemon740A. In this state, the technicalcomputing worker service270A is not available for remote calls from atechnical computing client270. As such, theactivation daemons740A-740N provide persistence and maintain the state of the technicalcomputing worker services270A-270N.
• The activation feature of technicalcomputing worker services270A-270N saves computing resources on workstations hosting the technical computing worker, and also increases service reliability. For example, if the technicalcomputing worker service270A terminates abruptly, theactivation daemon740A will automatically restart the next time a call is made to it. Theactivation daemon740A-740N also provides for the graceful termination of the technicalcomputing worker service270A-270N. If an inactivate command is sent to a technicalcomputing worker service270A-270N, the technicalcomputing worker service270A-270N can complete the processing of outstanding method calls before terminating. Alternatively, a command can be sent to thetechnical computing worker270A-270N to force immediate termination in the middle of processing a task. Additionally, in one embodiment, atechnical computing worker270A can be configured and controlled to shutdown after the completion of processing of a task. If thetechnical computing worker270A is not shutdown, it can be further configured to keep the state of the technical computing environment, including any calculation or other workspace information, intact for the next task that may be processed.
• In another embodiment of the technical computer worker service, the technicalcomputing worker services270A-270N can default to a non-debug mode when the technicalcomputing worker service270A-270N is started, either by theactivation daemon740A-740N or by other conventional means. Alternatively, theactivation daemon740A-740N and/or the technicalcomputing worker service270A-270N can be configured to start in debug mode, giving access to command line interface of thetechnical computing worker270A-270N.
• In a manner similar to technicalcomputing worker services270A-270N, thejob managers265A-265N and automatictask distribution mechanisms260A-260N as depicted inFIG. 7 can also be implemented as services. As such, thejob managers265A-265N and automatictask distribution mechanisms260A-260N can support lookup registration and discovery so that atechnical computing client250A can find the service without knowing the associated name of the service, the host name of theserver160 running the service, or the port name the service is listening on. Additionally, thejob manager265A-265N and automatic taskdistribution mechanism services260A-260N can be supported by activation daemons as with the technicalcomputing worker services270A-270N.
• In another aspect of the invention, the services of thetechnical computing worker270A-270N,job manager265A-265N and the automatictask distribution mechanism260A-260N, can also have administration functions in addition to the operational functions discussed above. Administration functions may include such functionality as determining the current status of the service, or calling debug functions on the service, or manually calling specific methods available from the service. As depicted inFIG. 7, thetechnical computing workers270A-270N may each include a technical computing workeradministration software component740A-740B, thejob managers265A-265N may each include a job manageradministration software component730A-730B, and the automatictask distribution mechanisms260A-260N may also each include anadministration software component760A-760N. Any and each of these administration software components may be part of the respective service, or a separate software component, or another service in itself. Additionally, these administration software components may include a graphical user interface for easier administration of the service. From the graphical user interface, a user may be able to exercise a portion or all of the functionality provided by the administration component and/or the methods provided by the service. Any of these administration functions may be not be available to users of thetechnical computing client250, and may be configured to only be available to system administrators or to those users with certain access rights to such functionality.
• For example, theadministration component760A of the automatictask distribution mechanism260A may provide a graphical view showing the tasks and results currently in the automatic task distribution mechanism. It may further show the movement of tasks and results in and out of the automatic task distribution mechanism along with the source and destinations of such tasks and results. Additionally, the graphical user interface may allow the user to set any of the properties and execute any of the methods described in the object-oriented interface to the object exchange repository664, or space, as described in the user defined data classes below.
• In another example, the jobmanager administration component730A may provide a graphical view of all the jobs in thejob queue267 of thejob manager265. It may further show the status of the job and the state of execution of each of the tasks comprising the job. The graphical user interface may allow the user to control the jobs by adding, modifying or deleting jobs, or arranging the order of the job in thequeue267. Additionally, the graphical user interface may allow the user to set any of the properties and execute any of the methods described in the object-oriented interface to the job manager266 as described in the user defined data classes below.
• A graphical user interface to the technical computingworker administration component750A-750N may provide a user the ability to change the activation state, stop and start, or debug the technicalcomputing worker service270A-270N. Additionally, the graphical user interface may allow the user to set any of the properties and execute any of the methods described in the object-oriented interface to thetechnical computer worker270A-270N as described in the user defined data classes below.
• Another aspect of this invention is the use of objects to perform object-oriented user interaction with the task and job management functionality of the distributed system.FIG. 8A depicts one embodiment of using user defined data classes as part of the MATLAB® programming language. In the object-oriented distributedsystem800 embodiment of the present invention, thesystem800 makes use of task objects810, result objects812, job objects814 and jobresults objects816 These objects present a lower level user interaction mechanism to interact with the task distribution functionality of thesystem800.
• In the object-oriented distributedsystem800 ofFIG. 8A, thetechnical computing client250 creates or declares atask object810. Thetask object810 is a user defined data class containing a MATLAB® command, input data and number of arguments. Thetechnical computing client250 submits the task object, in the automated mode of operation, to the automatictask distribution mechanism260, which stores thetask object810 in theobject exchange repository662. Atechnical computing worker270 listening and waiting for atask object810 to appear in theobject exchange repository662, takes thetask object810 to perform technical computing of the task. Thetechnical computing worker270 obtains the MATLAB® command and arguments from the properties of thetask object810 and performs technical computing on the task in accordance with the command. Thetechnical computing worker270 then creates or specifies aresult object812, which is a user defined data object containing the output data resulting from the execution of a task represented by atask object810. Thetechnical computing worker270 then writes theresult object812 to theobject exchange repository662. Thetechnical computing client250 listens and waits for the appearance of theresult object812 in theobject exchange repository662. After theresult object812 appears in the object exchange repository, thetechnical computing client250 takes theresult object812 from the object exchange repository and retrieves result information from the properties of theresult object812.
• Referring still toFIG. 8A, in batch mode, thetechnical computing client250 creates or declares ajob object814, which is a user defined data object containing an array of task objects810. Thetechnical computing client250 then submits thejob object814 to thejob manager265 for processing. Thejob manager265 then submits the one or more task objects820 defined in thejob object814 to theobject exchange repository662 for processing by atechnical computing worker270. Thetechnical computing worker270 listening for the appearance of the task objects820, takes the task objects820 and performs technical computing on the function as defined by each task object. Thetechnical computing worker270 then generates results and creates or specifies the result objects822 representing the output generated for each function of each of the task objects820 of thejob object814. Thetechnical computing worker270 then writes the result objects822 to theobject exchange repository662. Thejob manager662 listening for the appearance of the result objects822 takes the result objects from theobject exchange repository662. Thejob manager265 then creates or specifies the jobresults object816, which in an object that provides an array of result objects844 for each task object defined in ajob object814. The job manager then provides the jobresults object816 to thetechnical computing client250. One ordinarily skilled in the art will recognize the various combinations of uses of each of these objects in performing the operation of the multiple modes of distribution as depicted inFIG. 4.
• In an embodiment of the invention as depicted inFIG. 8A and by way of example, the following functions and properties are available in the programming language of MATLAB® via toolbox functionality of MATLAB® for task distribution management functionality:
TaskProperties

• Property Name	Property Description
  TaskID	unique task identifier
  JobID	non-null if this task is part of a job
  FunctionNameAndParameters	name of function and parameters of
  	function
  NumberOfOutputArguments	number of output arguments of function
  StartTime	startTime

Methods

• 	Method Name	Method Description
  	evaluate	evaluates function and returns Result

ResultProperties

• Property Name	Property Description
  TaskID	unique identifier given to corresponding task object
  JobID	non-null if this result is part of a job
  OutputArguments	output arguments
  StartTime	start time
  EndTime	end time
  WorkerName	name of work performing function
  ErrorMessage	error message, if any

WorkerProperties

• Property Name	Property Description
  Name	assigned name of worker service
  MachineName	name of computer worker service is running on
  TaskCompletedFcn	called whenever the worker finishes a directly
  	evaluated task
  Admin	instance of WorkerAdmin class

Methods

• Method Name	Method Description
  evaluateTask	evaluate the function defined by instance of Task class
  getResult	get instance of Result class generated by evaluatetask

WorkerAdminProperties

• 	Property Name	Property Description
  	Worker	instance of Worker class

Methods

• Method Name	Method Description
  destroy	removes all traces of the MATLAB service
  stop	unregisters the service but maintains files on disk
  deactivate	stops the MATLAB process, but does not
  	unregister service
  activate	starts the MATLAB process
  isActive	returns true if the MATLAB process is running
  isBusy	returns true if MATLAB is processing task or
  	otherwise busy
  isProcessingTask	returns true if MATLAB is processing task
  currentTask	returns the task being processed if idle, returns
  	null
  dbstop	basic debugging commands
  dbstep	basic debugging commands
  dbcont	basic debugging commands
  break	sends Ctrl-C
  isLogging	returns true if logging is turned on
  log	L = 0 turns off logging L = 1 turns on logging
  getStats	output arg format (return argument contents not
  	yet determined)
  clearResults	makes uncollected results available for garbage
  	collection
  listen	listen to the space for the appearance of task
  	objects
  getMachineProperties	return a structure of machine specific information
  	(system load, processor speed, amount of
  	memory, number of processors, etc)

SpaceProperties

• 	Property Name	Property Description
  	Name	name of space
  	MachineNme	host name of computer running the space
  	RsultAvailableFcn	name of function to call
  	SpaceAdmin	returns an instance of the SpaceAdmin class

Methods

• Method Name	Method Description
  putTask	the task will be written to the space
  getTask	a task will be taken from the space. This will block
  	until a task is found. If passed a null, a task with any
  	TaskID will be returned.
  getTaskIfAvailable	will return null if no task is immediately available
  putResult	will place a result into the JavaSpace
  getResult	works the same as gettask, except a result will be
  	taken rather than a task.
  getResultIfAvailable	will return null if no result with the corresponding
  	TaskID is available

SpaceAdminProperties

• 	Property Name	Property Description
  	Space	name of space

Methods

• Method Name	Method Description
  destroy	destroy the space
  clearSpace	removes all entries in this space
  cancelTask	removes the task or result matching TaskID from the
  	space
  numTasks	returns the number of tasks currently in the space
  numTesults	returns the number of results currently in the space
  workers	list MATLAB workers listening to space
  clearWorkers	unregister all listening workers
  addWorker	add a MATLAB worker as a listener
  removeWorker	remove the given MATLAB worker
  setEvalAttempts	set the number of times a task will be attempted
  isLogging	returns true if logging is turned on
  log	L = 0 turns off logging L = 1 turns on logging
  getStats	output arg format (return argument contents not yet
  	determined
  getTasks	removes and returns all tasks in the space in a cell
  	array
  getResults	removes and returns all results in the space in a cell
  	array
  readTasks	non-destructively returns all tasks in the space in a cell
  	array
  readResults	non-destructively returns all results in a cell array

JobProperties

• 	Property Name	Property Description
  	JobID	unique identifier for this job
  	Name	name of job
  	Tasks	cell array of task objects
  	UserName	name of user who creates job (user login name)
  	JobCompletedFcn	callback to execute when this job is finished
  	StartTime	start time of job

Methods

• Method Name	Method Description
  addTask	can add either a single task or a cell array of tasks
  removeTask	can remove either a single task or a cell array of tasks

JobResultsProperties

• 	Property Name	Property Description
  	JobID	unique identifier for job
  	Name	name of job
  	Username	name of user who created job
  	Results	cell array of result objects
  	StartTime	start time of job
  	EndTime	end time of job

JobManagerMethods

• Method Name	Method Description
  submitJob	submits a Job object to the job manager
  getResults	returns a JobResults object. Will block until job is
  	finished
  getResultsIfAvailable	returns a JobResults object or null. Will return
  	immediately
  getResult	gets a result of instance of a task
  getResultIfAvailable	get a result of instance of a task if result is
  	available

JobManagerAdminProperties

• 	Property Name	Property Description
  	JobManager	instance of JobManager class
  	Space	the space associated with this job manager

Methods

• 	Method Name	Method Description
  	clearJobs	clears the job queue
  	promote	promotes the specified job
  	demote	demotes the specified job
  	promoteFirst	promote the job to the top of the queue
  	demoteLast	demote the job to the bottom of the queue
  	cancelJob	removes the job from the queue
  	getStatus	returns ‘executing’,’completed’,’
  	getInfo	gets information for all waiting jobs except for the
  		task objects
  	readJobs	non-destructively returns all jobs in the queue

• The following methods are generally available methods in a package of the MATLAB programming environment, which in this exemplary embodiment have not been implemented as user defined data classes:
Package Scope Methods (Not Part of Any Class)

• findWorkers	finds MATLAB workers available on the network.
  	Returns a cell array of worker objects.
  findSpaces	finds spaces available on the network. Returns a cell
  	array of space objects.
  findJobManagers	finds jobmanagers available on the network. Returns
  	a cell array of JobManager objects.

  
  The above package scope methods are used to find the services oftechnical computing workers270A-270N, automatictask distribution mechanisms260A-260N, or spaces, andjob managers265A-265N as depicted inFIG. 7. With these methods, atechnical computing client250 does not need to have previous knowledge of anytechnical computing worker270A-270N, any of the automatictask distribution mechanisms260A-260N or anyjob managers265A-265N. Thetechnical computing client250 can use these methods to discover the name and number of such services available on thenetwork140.
• In an embodiment of the present invention, the programming language of MATLAB® may support the three modes of operation as described withFIGS. 3A-3C. By way of example, the following program instructions show a programming usage of the above described user defined data classes for each of these modes of operation:
Direct Distribution Usage Example

• 	% Find worker
  	w = distcomp.Worker(‘MachineName’)
  	% Create task
  	t = distcomp.Task({‘rand’,10},1);
  	% (Optional) register completed callback for worker
  	w.TaskCompletedFcn = ‘completedFcn’;
  	% (Optional) set task timeout value
  	t.Timeout = 10;
  	% Send task to worker
  	w.evaluateTask(t);
  	% Get result (could take place inside completed callback function)
  	r = w.getResult(t);

Automated Distribution Usage Example

• 	% Find space
  	s = distcomp.Space(‘spacename’)
  	% Create task
  	t = distcomp.Task({‘rand’,10},1)
  	% (Optional) Register completed callback for space
  	s.TaskCompletedFcn = ‘completedFcn’;
  	% (Optional) set task timeout value
  	t.timeout = 10;
  	% Put task in space
  	s.putTask(t);
  	% Get result from space (could be inside result listener)
  	r = s.getResult(t);

Batch Processing Usage Example

• 	% Find Job Manager
  	jm = distcomp.JobManager(‘managername’)
  	% Create job
  	j = distcomp.Job(‘username’,’jobname’)
  	% (optional) register callback for job completion
  	j.JobCompletedFcn = ‘callbackFcn’;
  	% Add tasks to job
  	for(i=1:10)
  	t = distcomp.Task({‘rand’,10},1);
  	% (optional) register completed callback for task
  	t.CompletedFcn = ‘callbackFcn’;
  	% (optional) set task timeout value
  	t.Timeout = 10;
  	j.addTask(t);
  	end
  	jm.submit(j)
  	% Get results from job manager
  	for(i=1:10)
  	r = jm.getResult(j.Tasks {i});
  	% insert code to process result here
  	end

• In addition to the object-oriented interface to task and job management functionality of the distributed system, the programming language of MATLAB® may also support task distribution via high-level functional procedure calls. The MATLAB® programming language includes procedural function calls such as eval( ) and feval( ) that provide a quick and powerful procedure to execute functions. Also, the MATLAB® programming enables you to write a series of MATLAB® statements into a file, referred to as an M-File, and then execute the statements in the file with a single command. M-files can be scripts that simply execute a series of MATLAB® statements, or they can be functions that also accept input arguments and produce output. Additionally, the MATLAB® programming language supports anonymous functions and function handles. Function handles are useful when you want to pass your function in a call to some other function when that function call will execute in a different workspace context than when it was created. Anonymous functions give you a quick means of creating simple functions without having to create M-files each time and can be viewed as a special subset of function handles. An anonymous function can be created either at the MATLAB® command line or in any M-file function or script. Anonymous functions also provide access to any MATLAB® function. The @ sign is the MATLAB® operator that constructs a function handle or an anonymous function, which gives you a means of invoking the function. Furthermore, the MATLAB® programming language enables the association of a callback function with a specific event by setting the value of the appropriate callback property. A variable name, function handle, cell array or string can be specified as the value of the callback property. The callback properties for objects associated with the MATLAB®-based distributed computing application are designed to accept any of the above described configurations as the value of the callback property, and may accept any other command, function or input parameter value that are or may become available in the MATLAB® programming language. This allows users of the MATLAB® programming language to use the function calls they are familiar with, without learning the object-oriented mechanism, and take advantage of the distributed processing of tasks offered by the MATLAB®-based distributed computing application of the present invention.
• In the exemplary object-oriented distributedsystem805 ofFIG. 8B, thetechnical computing client250 creates or declares ajob object860 residing in thejob manager265. The job object comprises one or more task objects870A-870N. Thejob object860 further defines properties associated with the job, such as those job properties described in further detail below. For example, a timeout property to specify the time limit for completion of a job. Additionally, the minimum and maximum number of technical computing workers to perform the tasks of the job can be set. The task object870A-870N is an object that defines a function to be executed by atechnical computing worker270. The function contains a MATLAB® command, input data and number of arguments. The task object870A-870N defines additional task properties, such as those defined below. For example, the task object870A-870N may have a state property to indicate the current state of the task. Additionally, thetechnical computing client250 may interface with thejob manager265 through ajob manager object865 residing on thejob manager265. In a similar manner to thejob object860 and task objects870A-870N, thejob manager object865 may have properties to define configuration and other details about thejob manager265 as described below. For example, thejob manager object865 may have a hostname property to indicate the name of the computer where a job queue exists, or a hostaddress property to indicate the internet protocol address of the computer. For any of thejob manager object865,job object860 or task objects870A-870N, the technical computing client may not instantiate a local object but may just have a proxy or facade object to reference the object existing in thejob manager265.
• Still referring toFIG. 8B, thetechnical computing client250 submits the job to thejob manager265 via thejob object865. Thejob manager265 obtains each of the task objects870A-870N from thejob object865. The job manager puts the job of thejob object860 into thejob queue267. Thejob runner667 obtains the one or more task objects870A-870N from thejob object860. Thejob runner667 with theworker pool668 determines atechnical computing worker270 to process a task. Thejob runner667 then submits a task, via atask object870A-870N to an assignedtechnical computing worker270. Thetechnical computing worker270 obtains the function to execute from the properties of the task object870A-870N and performs technical computing of the task in accordance with the function. Thetechnical computing worker270 then obtains the results of the function and updates one or more properties of the task object870A-870N with information about the results. In the case of any errors, thetechnical computing worker270 may update any error properties of the task object870A-870N. In a similar manner as thetechnical computing client250, thetechnical computing worker270 may use proxy or facade objects to interface with thejob860,job manager865 ortask870A-870N objects residing in thejob manager265. Thejob manager265 then updates thejob object860 with updated task objects870A-870N containing the results of each task. Thejob manager265 may also update other properties of thejob object860, such as start and finish times of the job, to reflect other information or status of the job. Thejob manager265 then provides the updatedjob object860 to thetechnical computing client250. Thetechnical computing client250 then can retrieve the results of each task from the updatedjob object860. One ordinarily skilled in the art will recognize the various combinations of uses of the properties and functions of these objects in performing the operations described herein and in support of any of the multiple modes of distribution as depicted inFIG. 4.
• In an exemplary embodiment of the invention as depicted inFIG. 8B and by way of example, the following functions and properties may be available in the programming language of MATLAB® for creating and handling objects related to the task distribution and management functionality of the present invention:
Function Reference
• createJob

• Purpose	Create a job object
  Syntax	obj = createJob(jobmanager)
  	obj = createJob(. . . , ‘p1’, v1, ‘p2’, v2, . . . )

  Arguments	obj	The job object.
  	jobmanager	The job manager object representing the job manager service that
  		will execute the job.
  	p1, p2	Object properties configured at object creation.
  	v1, v2	Initial values for corresponding object properties.

  Description	obj = createJob(jobmanager) creates a job object at the specified remote location.
  	In this case, future modifications to the job object result in a remote call to the job
  	manager.
  	obj = createJob(. . . , ‘p1’, v1, ‘p2’, v2, . . . ) creates a job object with the specified
  	property values. If an invalid property name or property value is specified, the
  	object will not be created.
  	Note that the property value pairs can be in any format supported by the set
  	function, i.e., param-value string pairs, structures, and param-value cell array
  	pairs.
  Example	% construct a job object.
  	jm = findResource(‘jobmanager’);
  	obj = createJob(jm, ‘Name’, ‘testjob’);
  	% add tasks to the job.
  	for i=1:10
  	createTask(obj, ‘rand’, {10});
  	end
  	% run the job.
  	submit(obj);
  	% retrieve job results.
  	out = getAllOutputArguments(obj);
  	% display the random matrix.
  	disp(out{1}{1});
  	% destroy the job.
  	destroy(obj);

  
  createTask

• Purpose	Create a new task in a job
  Syntax	obj = createTask(j, functionhandle, numoutputargs, inputargs)
  	obj = createTask( . . . , ‘p1’, v1, ‘p2’, v2, . . . )

  Arguments	j	The job that the task object is created in.
  	functionhandle	A handle to the function that is called when the task is
  		evaluated.
  	numoutputargs	The number of output arguments to be returned from
  		execution of the task function.
  	inputargs	A row cell array specifying the input arguments to be
  		passed to the function functionhandle. Each element in the
  		cell array will be passed as a separate input argument.
  	p1, p2	Task object properties configured at object creation.
  	v1, v2	Initial values for corresponding task object properties.

  Description	obj = createTask(j, functionhandle, numoutputargs, inputargs)
  	creates a new task object in job j, and returns a reference, obj, to the added
  	task object.
  	obj = createTask( . . . , ‘p1’, v1, ‘p2’, v2, . . . ) adds a task object with the
  	specified property values. If an invalid property name or property value is
  	specified, the object will not be created.
  	Note that the property value pairs can be in any format supported by the set
  	function, i.e., param-value string pairs, structures, and param-value cell array
  	pairs.
  Example	% create a job object.
  	jm = findResource(‘jobmanager’);
  	j = createJob(jm);
  	% add a task object to be evaluated that generates a 10 × 10 random matrix.
  	obj = createTask(j, @rand, {10,10});
  	% run the job.
  	submit(j);
  	% get the output from the task evaluation.
  	taskoutput = get(obj, ‘OutputArguments’);
  	% show the 10 × 10 random matrix.
  	disp(taskoutput{1});

  
  destroy

• Purpose	Remove a job or task object from its parent and from memory
  Syntax	Destroy(obj)
  Arguments	obj  Job or task object deleted from memory.
  Description	destroy(obj) removes the job object reference or task object reference obj from the
  	local session, and removes the object from the job manager memory. When obj is
  	destroyed, it becomes an invalid object. An invalid object should be removed
  	from the workspace with the clear command. If multiple references to an object
  	exist in the workspace, destroying one reference to that object invalidates the
  	remaining references to it. These remaining references should be cleared from the
  	workspace with the clear command. The task objects contained in a job will also
  	be destroyed when a job object is destroyed. This means that any references to
  	those task objects will also be invalid. If obj is an array of job objects and one of
  	the objects cannot be destroyed, the remaining objects in the array will be
  	destroyed and a warning will be returned.
  Remarks	Because its data is lost when you destroy an object, destroy should be used after
  	output data has been retrieved from a job object.
  Example	% destroy a job and its tasks.
  	jm = findResource(‘jobmanager’);
  	j = createJob(jm, ‘Name’, ‘myjob’);
  	t = createTask(j, @rand, {10});
  	destroy(j);
  	clear j
  	Note that task t is also destroyed as part of job j.

  
  destroyAllTasks

• Purpose	Remove all of a job's tasks from the job object and from memory
  Syntax	destroyAllTasks(obj)

  Arguments

  obj

  Job object whose tasks are deleted.

  Description	destroyAllTasks(obj) removes all tasks from the job object obj. The job itself
  	remains, and you can add more tasks to it. (By comparison, using destroy on the
  	job removes the job object entirely.)
  findJob
  Purpose	Find job objects stored in a job manager
  Syntax	findJob(jm)
  	out = findJob(jm)
  	[pending queued running finished] = findJob(jm)
  	out = findJob(jm, ‘p1’, v1, ‘p2’, v2, . . . )

  Arguments

  jm

  Job manager object in which to find the job.

  	pending	Array of jobs in job manager jm whose State is pending.
  	queued	Array of jobs in job manager jm whose State is queud.
  	running	Array of jobs in job manager jm whose State is running.
  	finished	Array of jobs in job manager jm whose State is finished.
  	out	Array of jobs found in job manager jm.
  	p1, p2	Job object properties to match.
  	v1, v2	Values for corresponding object properties.

  Description	findJob(jm) prints a list of all of the job objects stored in the job manager jm. Job
  	objects will be categorized by their State property and job objects in the ‘queued’
  	state will be displayed in the order in which they are queued, with the next job to
  	execute at the top (first). out = findJob(jm) returns an array, out, of all job objects
  	stored in the job manager jm. Jobs in the array will be ordered by State in the
  	following order: ‘pending’, ‘queued’, ‘running’, ‘finished’; within the ‘queued’ state,
  	jobs are listed in the order in which they are queued. [pending queued running
  	finished] = findJob(jq) returns arrays of all job objects stored in the job manager
  	jm, by state. Jobs in the array queued will be in the order in which they are
  	queued, with the job at queued(1) being the next to execute. out = findJob(jm,
  	‘p1’, v1, ‘p2’, v2, . . . ) returns an array, out, of job objects whose property names and
  	property values match those passed as parameter-value pairs, p1, v1, p2, v2.
  	Note that the property value pairs can be in any format supported by the get
  	function, i.e., param-value string pairs, structures, and param-value cell
  	arraypairs. If a structure is used, the structure field names are job object property
  	names and the field values are the requested property values. Jobs in the queued
  	state are returned in the same order as they appear in the job queue service. When
  	a property value is specified, it must use the same format that the get function
  	returns. For example, if get returns the Name property value as MyJob, then
  	findJob will not find that object while searching for a Name property value of
  	myjob.

  
  findResource

• Purpose	Find available MATLAB ®-based application resources
  Syntax	findResource(‘type’)
  	out = findResource(‘type’)
  	out = findResource(‘type’, ‘p1’, v1, ‘p2’, v2, . . . )

  Arguments	out	Object or array of objects returned.
  	p1, p2	Object properties to match.
  	v1, v2	Values for corresponding object properties.

  Description	findResource(‘type’) displays a list of all the available MATLAB ®-based
  	distributed computing application resources of type given by the string type, that
  	have the ability to run a job. Possible types include ‘jobmanager’, localsession’,
  	‘mlworker’. out = findResource(‘type’) returns an array, out, containing objects
  	representing all available MATLAB ®-based distributed computing application
  	resources of the given type. out = findResource(‘type’, ‘p1’, v1, ‘p2’, v2, . . . ) returns
  	an array, out, of resources of the given type whose property names and property
  	values match those passed as parameter-value pairs, p1, v1, p2, v2. Note that the
  	property value pairs can be in any format supported by the get function, i.e.,
  	param-value string pairs, structures, and param-value cell array pairs. If a
  	structure is used, the structure field names are object property names and the field
  	values are the requested property values. When a property value is specified, it
  	must use the same format that the get function returns. For example, if get returns
  	the Name property value as MyJobManager, then findResource will not find that
  	object while searching for a Name property value of myjobmanager.
  Remarks	The only supported types of resources is jobmanager. Note that some parameter-
  	value pairs are queried on the local machine, while others require a call directly to
  	the job manager to query. The parameter-value  pairs that require a call to the
  	job manager will take longer to query than those
  	‘type’ Type of resource to find that can be queried locally. The properties that are
  	known locally are: Type, Name, HostName, and Address. Note that it is
  	permissible to use parameter-value string pairs, structures, and parameter-value
  	cell array pairs in the same call to findResource.
  Example	jm1 = findResource(‘jobmanager’, ‘Name’, ‘jobmanager1name’);
  	jm2 = findResource(‘jobmanager’, ‘Name’, ‘jobmanager2name’);

  
  findTask

• Purpose	Get the task objects belonging to a job object
  Syntax	tasks = findTask(obj)
  	tasks = findTask(obj, range)
  	tasks = findTask(obj, ‘p1’, v1, ‘p2’, v2, . . . )

  Arguments	obj	Job object.
  	range	A scalar or vector list of indexes specifying which tasks to return.
  		tasks returned task objects.
  	p1, p2	Task object properties to match.
  	v1, v2	Values for corresponding object properties.

  Description	tasks = findTask(obj) and tasks = findTask(obj, range) get tasks belonging to a
  	job object obj, where range is a scalar or vector list of indexes specifying which
  	tasks to return. tasks = findTask(obj, ‘p1’, v1, ‘p2’, v2, . . . ) gets a 1 × N array of task
  	objects belonging to a job object obj. The returned task objects will be only those
  	having the specified property-value pairs. Note that the property value pairs can
  	be in any format supported by the get function, i.e., param-value string pairs,
  	structures, and param-value cell array pairs. If a structure is used, the structure
  	field names are object property names and the field values are the requested
  	property values. When a property value is specified, it must use the same format
  	that the get function returns. For example, if get returns the Name property value
  	as MyTask, then findTask will not find that object while searching for a Name
  	property value of mytask.
  Remarks	If obj is contained in a remote service, findTask will result in a call to the remote
  	service. This could result in findTask taking a long time to complete, depending
  	on the number of tasks retrieved and the network speed. Also, if the remote
  	service is no longer available, an error will be thrown.
  	If obj is contained in a remote service, you can issue a {circumflex over ( )}C (Control-C) while
  	findTask is blocking. This returns control to MATLAB. In this case, another
  	remote call will be necessary to get the data.
  Example	% create a job object.
  	jm = findResource(‘jobmanager’);
  	obj = createJob(jm);
  	% add a task to the job object.
  	createTask(obj, @rand, {10})
  	% assign to t the task we just added to obj.
  	t = findTask(obj, 1)

  
  getAllOutputArguments

• Purpose	Retrieve output arguments from evaluation of all tasks in a job object
  Syntax	data = getAllOutputArguments(obj)

  Arguments	obj	Job object whose tasks generate output arguments.
  	data	Cell array of job results.

  Description	data = getAllOutputArguments(obj) returns data, the output data contained in the
  	tasks of a finished job. Each element of the 1 × N cell array data contains the output
  	arguments for the corresponding task in the job, that is, each element is a cell
  	array. If no output data is returned for a task, then that
  	element will contain an empty cell array as a placeholder. The order of the
  	elements in data will be the same as the order of the tasks contained in the job.
  Remarks	Because getAllOutputArguments results in a call to a remote service, it could take
  	a long time to complete, depending on the amount of data being retrieved and the
  	network speed. Also, if the remote service is no longer available, an error will be
  	thrown. You can issue a {circumflex over ( )}C (control-C) while getAllOutputArguments is
  	blocking. This does not stop the data retrieval, but returns control to MATLAB. In
  	this case, another remote call is necessary to get the data. Note that issuing a call
  	to getAllOutputArguments will not remove the output data from the location
  	where it is stored. To remove the output data, use the destroy function to remove
  	either the task or its parent job object, or use destroyAllTasks.
  Example	jm = findResource(‘jobmanager’);
  	j = createJob(jm, ‘Name’, ‘myjob’);
  	t = createTask(j, @rand, {10});
  	submit(j);
  	data = getAllOutputArguments(t);
  	% display a 10 × 10 random matrix
  	disp(data{1});
  	destroy(j);

  
  submit

• Purpose	Queue a job in a job queue service
  Syntax	submit(obj)
  Arguments	obj  Job object to be queued.
  Description	submit(obj) queues the job object, obj, in the resource where it currently resides.
  	The resource where a job queue resides is determined by how the job was created.
  	A job may reside in the local MATLAB session, in a remote job manager service,
  	or in a remote MATLAB worker service. If submit is called with no output
  	arguments, then it is called asynchronously, that is, the call to
  	submit returns before the job is finished. An exception to this rule is if the job
  	resides in the local MATLAB session, in which case the submit always executes
  	synchronously.
  Remarks	When a job contained in a job manager is submitted, the job's State property is set
  	to queued, and the job is added to the list of jobs waiting to be executed by the job
  	queue service. The jobs in the waiting list will be executed in a first in, first out
  	manner, that is, the order in which they were submitted.
  Example	% find a job manager service named jobmanager1.
  	jm1 = findResource(‘jobmanager’, ‘Name’, ‘jobmanager1’);
  	% create a job object.
  	j1 = createJob(jm1);
  	% add a task object to be evaluated for the job.
  	t1 = createTask(j1, @myfunction, {10, 10});
  	% queue the job object in the job manager.
  	submit(j1);

Property ReferenceJob Manager Object Properties

• Property Name	Property Description
  HostName	Indicate name of the machine where a job queue exists
  HostAddress	Indicate the IP address of the host machine where a
  	job queue exists
  ID	Indicate a job manager object's identifier
  JobCreatedFcn	Specify the M file function to execute when a job is
  	created in a job queue
  JobFinishedFcn	Specify the M file function to execute when jobs finish in
  	a job queue
  JobQueuedFcn	Specify the M file function to execute when jobs are
  	queued
  JobRunningFcn	Specify the M file function to execute when job are run
  	in a job queue
  Jobs	Indicate the jobs contained in a job manager
  Name	Indicate the name of the job manager
  State	Indicate the current state of the job manager

Job Object Properties

• Property Name	Property Description
  FinishedFcn	Specify the callback to execute when a job finishes running
  FinishTime	Indicate when a job finished
  ID	Indicate a job object's identifier
  MaximumNumberOfWorkers	Specify maximum number of workers to perform the tasks
  	of a job
  MinimumNumberOfWorkers	Specify minimum number of workers to perform the tasks
  	of a job
  Name	Specify a name for a job object
  QueuedFcn	Specify M file function to execute when job added to queue
  RestartWorker	Specify whether to restart MATLAB on a worker before it
  	evaluates a task
  RunningFcn	Specify the M file function to execute when a job or task
  	starts running
  StartTime	Indicate when a job started running
  State	Indicate the current state of a job object
  TaskCreatedFcn	Specify the M file function to execute when a task is created
  TaskFinishedFcn	Specify the M file function to execute when tasks finish in
  	job queue
  TaskRunningFcn	Specify M file function to execute when a task is run
  Tasks	Indicate the tasks contained in a job object
  Timeout	Specify time limit for completion of a job

Task Object Properties

• Property Name	Property Description
  CaptureCommandWindowOutput	Specify whether to return command window output
  CommandWindowOutput	Indicate text produced by execution of task object's function
  ErrorID	Indicate task error identifier
  ErrorMessage	Indicate output message from task error
  FinishedFcn	Specify the callback to execute when a task finishes running
  FinishTime	Indicate when a task finished
  Function	Indicate the function called when evaluating a task
  ID	Indicate a task object's identifier
  InputArguments	Indicate the input arguments to the task object
  NumberOfOutputArguments	Indicate the number of arguments returned by the task
  	function
  OutputArguments	The data returned from the execution of the task
  RunningFcn	Specify the M file function to execute when a job or task
  	starts running
  State	Indicate the current state of a task object
  StartTime	Indicate when a task started running
  Timeout	Specify time limit for completion of a task

• In alternative embodiments, the object-oriented interfaces and/or functional procedures available in the MATLAB® programming language, may be available in one or more application programming interfaces, and may be available in one or more libraries, software components, scripting languages or other forms of software allowing for the operation of such object-oriented interfaces and functional procedures. One ordinarily skilled in the art will appreciate the various alternative embodiments of the above class definitions, class method and properties, package scope methods, functional procedures and programming instructions that may be applied to manage the distribution of tasks and jobs for distributed technical computing processing of the present invention.
• From an overall perspective and in view of the structure, functions and operation of MATLAB® as described herein, the current invention presents many advantages for distributed, streaming and parallel technical computing processing systems as depicted inFIGS. 9A and 9B. The MATLAB®-based distributed computing system can handle a wide variety of user configurations from a standalone system to a network of two machines to a network of hundreds of machines, and from a small task granularity to an extremely large task granularity of parallel, and parallel and serial technical computing.
• Referring toFIG. 9A, the distributed system910 supports the delegation of tasks from atechnical computing client250 to remotetechnical computing workers270A-270N leveraging the processing capability of each of theworkstations170A-170N hosting each of thetechnical computing workers270A-270N. The tasks are executed independently of each other and do not require thetechnical computing workers270A-270B to communicate with each other.
• Still referring toFIG. 9A, the streaming, or serial, processing system910 allows serial processing to occur via multipletechnical computing workers270A-270N onmultiple workstations170A-170N. Atechnical computing client250A submits a job requiring a task to be processed serially fromtechnical computing worker270A totechnical computing worker270B then totechnical computing worker270N. Whentechnical computing worker270A completes its technical computing of the task,technical computing worker270A submits the task totechnical computing worker270B for further processing. In a similar fashion, the task can be submitted to additionaltechnical computing workers270N for further processing until the task is complete in accordance with its task definition. The lasttechnical computing worker270N to perform technical computing on the task submits the result to thetechnical computing client250.
• The streaming processing system920 can take advantage ofspecific workstations170A-170N that may have faster processors for performing processor intensive portions of technical computing of the task or take advantage oftechnical computing workers270A-270N with access to specific data sets or external control instrumentation as required for computation of the task.
• InFIG. 9B, a parallel system930 is depicted which combines the distributed and streaming configuration of the systems (900 and910) inFIG. 9A. In brief overview,technical computing workers270A and270B and270N can be executing a set of tasks independently of each other. Additionally, these technical computing workers can then submit tasks to other technical computing workers to perform technical computing of a task in a streaming fashion. For example,technical computing worker270A can submit a task for further processing totechnical computing worker270B, and in turn,technical computing worker270B can submit the task for further processing bytechnical computing worker270N. Thetechnical computing worker270N when it completes processing may return a result back to the automatictask distribution mechanism260 or thetechnical computing client250. This configuration provides for great flexibility in determining how to best distribute technical computing tasks for processing based on many factors such as the types and availability of computing devices, network topology, and the nature and complexity of the technical computing problem being solved.
• B. Instrument-Based Distributed Computing System
• The illustrative embodiment of the present invention provides an instrument-based distributed computing system using the technical computing client and the technical computing worker. The instrument-based distributed computing system includes one or more instruments connected through a network. The instruments may be provided on a PC-based platform or other platform and have capacities to run additional software product, such as the technical computing client and the technical computing worker. The instrument-based distributed computing system may operate in a test environment for testing a unit under test. One of ordinary skill in the art will appreciate that the instrument is illustrative test equipment and the present invention may apply to other test equipment or components, such as a virtual instrument that includes an industry-standard computer or workstation equipped with application software, hardware such as plug-in boards, and driver software, which together perform the functions of traditional instruments.
• In the instrument-based distributed computing system, the technical computing client may reside in an instrument or a client device to create a job. The technical computing client then distributes the job to one or more remote technical compute workers for the distributed execution of the job. The technical computing workers may reside in other instruments or workstations on a network. The workers running on the instruments and/or workstations are available to the technical computing client so that the technical computing client can distribute the job to the workstations and the instruments. The technical computing workers execute the received portion of the job and return the execution results to the technical computing client. As such, the illustrative of the present invention executes a job or a test in a distributed fashion using the instruments and/or workstations on the network.
• FIG. 10 is a block diagram showing an exemplary instrument-based distributedsystem1000 in the distributed computing environment. The instrument-based distributedcomputing system1000 may include one ormore clients150,servers160,workstations170 andinstruments180 coupled to anetwork140. Theclient150,server160 and workstation may run thetechnical computing client250, theautomatic distribution mechanism260 and the technical computing worker, respectively, as described above with reference toFIGS. 1A-9B. Theinstrument180 may run thetechnical computing client250 and/or the technical computing worker depending on the configuration of the instrument based distributed computing system, which will be described below in more detail with reference toFIGS. 12A-12C. Those skilled in the art will appreciate that the instrument-based distributedsystem1000 is illustrative and may not include all of theclient150,server160,workstation170 andinstrument180. The instrument-based distributedsystem1000 can be implemented with a various combinations of theclient150,server160,workstation170 andinstrument180 in other embodiments.
• In the illustrative embodiment ofFIG. 10, theclient150,server160,workstation170 andinstrument180 are coupled to thenetwork140. Theclient150 orinstrument180 may communicate directly with theworkstation170 orother instruments180 as described above with reference toFIG. 3A. Theclient150 orinstrument180 may communicate with theworkstation170 orother instruments180 via theserver160, which runs the automatictask distribution mechanism260, as described above with reference toFIGS. 3B-4. Theworkstations170 orinstruments180 may or may not communicate with each other depending on the communication topology of the distributedcomputing system1000, as described above with reference toFIGS. 9A and 9B.
• FIG. 11 is a block diagram showing an exemplary instrument utilized in the illustrative embodiment of the present invention. Theinstrument180 may includeinstrumentation functionalities1110, atechnical computing client250, atechnical computing worker270, anoperating system1120 and anetwork interface118. Theinstrumentation functionalities1110 provide the instrument's own functionalities for test, measurement and automation, such as the functionalities for oscilloscopes and spectrum analyzers, that determine the present value of a quantity under observation. In the illustrative embodiment, theinstrument180 refers to any tool that includes one or more instrumentation functionalities.
• Thetechnical computing client250 and thetechnical computing worker270 installed on theinstrument180 may include the MATLAB®-based distributedcomputing application120 as described above with reference toFIGS. 2A-2C. Thetechnical computing client250 creates a job including one or more tasks. Thetechnical computing client250 distributes the job to the technical computing workers for the distributed execution of the job. Thetechnical computing worker270 performs technical computing tasks defined by theclient250. Theinstrument180 may include thetechnical computing client250 and/or thetechnical computing worker270. If theinstrument180 is installed with thetechnical computing client250, theinstrument110 may operate to generate a job and distribute the job toworkstations170 and/orother instruments180, as theclient150 does. If theinstrument180 is installed with thetechnical computing worker270, theinstrument110 may operate to receive and execute the tasks, as theworkstations170 do.
• Theinstrument180 may include an operating system1130 that enables users to install their own applications, such as thetechnical computing client250 and thetechnical computing worker270. The operating system1130 enables the applications to run on theinstrument180. Theinstrument180 may have, for example, a standard Windows® operating system so that the users can install their own applications on theinstrument180. The Windows operating system is an exemplary operating system that can be included in theinstrument180 and the operating system1130 may include any other operating systems described above with reference toFIG. 1A.
• Theinstrument180 may communicate with theclient150,server160,workstation170 orother instruments180 via thenetwork interface118. The network interface1130 may include any network interfaces described above with reference toFIG. 1A. Thenetwork interface118 may include a bus interface, such as a general purpose interface bus (GPIB) interface. The network interface1140 may also include any other bus interfaces, such as Universal Serial Bus (USB), Myrinet, Peripheral Component Interconnect (PCI), PCI extended (PCI-X), etc. In particular, the network interface1140 may include an LXI (LAN extension for instrumentation) interface, which is based on industry standard Ethernet technology.
• Theinstrument180 running the workers may have the capability of accelerating the execution of tasks. For example, the instrument may include hardware components, such as FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), DSP (Digital Signal Processor) and CPU (Central Processing Unit), to perform fast calculations of the tasks, such as FFT calculations. In particular, theinstrument180 may have multiple processors or CPUs to run the workers.
• Theinstrument180 may support a GPGPU (General-purpose Computing on Graphics Processing Units) process that uses the GPU (Graphics Processing Units) to perform the computations rather than the CPU. GPU is the mocroprocessor of a graphics card or graphics accelerator) for a computer or game console. GPU is efficient at manipulating and displayingcomputer graphics, and its parallel structure makes the GPU more effective than typical CPU for a range of complex algorithms. The GPU can also be used for general purposes in non-graphics areas, such as cryptography, databased operations, FFT, neural networks. One of skill in the art will appreciate that the workstations running the workers may support the GPGPU process.
• FIG. 12A is a block diagram showing another exemplary instrument-based distributed computing system. The instrument-based distributed computing system may include theclient150,workstations170 andinstruments180 coupled to thenetwork140. Thetechnical computing client250 runs on theclient150. The technical computing thetechnical computing workers270 may run on theworkstations170 andinstruments180. Thetechnical computing client250 creates a job and distributes the job to thetechnical computing workers270 on theworkstations170 andinstruments180. Thetechnical computing workers270 on theworkstations170 andinstruments180 execute the job and return the execution results to thetechnical computing client250 on theclient150. One of ordinary skill in the art will appreciate that the system may include a server for the automatic distribution of the tasks, as described above with reference toFIG. 10.
• FIG. 12B is a block diagram showing another exemplary instrument-based distributed computing system. The instrument-based distributed computing system may includeworkstations170 andinstruments180 coupled to thenetwork140. Thetechnical computing client250 runs on theinstrument180. Thetechnical computing workers270 run on theworkstations170 andother instruments180. Thetechnical computing client250 creates a job and distributes the job to thetechnical computing workers270 on theworkstations150 andinstruments180. Thetechnical computing workers270 on theworkstations170 andinstruments180 execute the job and return the execution results to the technical computing client on theclient150. One of ordinary skill in the art will appreciate that the system may include a server for the automatic distribution of the tasks, as described above with reference toFIG. 10.
• FIG. 12C is a block diagram showing an exemplary hierarchical structure of the instrument-based distributed computing system. The instrument-based distributed computing system may include theclient150,workstation170 andinstrument180 coupled to thenetwork140. The system may also include a sub-cluster190 coupled to thenetwork140. The sub-cluster190 may include clients, servers, workstations and instruments. The sub-cluster190 may run additional technical computing clients and technical computing workers to distribute and execute the job defined by thetechnical computing client250 on theclient150 orinstrument180. Thetechnical computing client250 may create a job and distribute the job to the sub-cluster190. The technical computing workers in the sub-cluster190 execute the job and return the execution results to thetechnical computing client250 on theclient150 orinstrument180. The sub-cluster190 may include a distribution mechanism for distributing the job to the workstations and instruments in the sub-cluster190.
• The instrument-based distributed computing system can be used in a test environment in the illustrative embodiment. The instrument that contains a computing capability, such as thetechnical computing client250 and thetechnical computing worker270, can perform a test. The computing capability of the instrument is used for processing data to perform a portion of the test defined by a client. The test environment utilizes the computing power of the instrument on a network to conduct a distributed execution of the test. In the description of the illustrative embodiment, a “test” refers to an action or group of actions that are performed on one or more units under test to verify their parameters and characteristics. The unit under test refers to an entity that can be tested which may range from a single component to a complete system. The unit under test may include software product and/or hardware devices.
• FIG. 13 is an example of atest environment1200 provided in the illustrative embodiment of the present invention. In thetest environment1200, various types ofresources1210 may be used for providing units undertest1230. One of skill in the art will appreciate that theresources1210 may include software tools and hardware tools. Thetest environment1200 may include atest manager1220. Using thetest manager1220, users may inputcontrol data1240 for setting conditions for testing the units undertest1230 in thetest environment1200. Thecontrol data1240 may include a sequence of test steps that specifies the ordering of the resources to be used by thetest manager1220. The users may also input the variables and parameters of the test that can be used as arguments to call the functions provided by theresources1210. Using different variables and parameters in the test, the functions of the units undertest1230 may return different values. The units undertest1230 may include one or more pieces of hardware, software and/or programs, such as models and/or code. One of skill in the art will appreciate that the units undertest1230 may include software tools and hardware tools. Thetest manager1220 conducts the test in different conditions using the sequence of the test steps and the variables and parameters of the test.
• The illustrative embodiment of the present invention may provide a test environment in which the users (or developers) of software tools are able to conduct a test for testing various types of units undertest1230. The test may include one or more test steps, such as a test step for testing a textual program, a test step for testing a graphical program, a test step for testing a function provided in a software tool, a test step for testing a hardware device, etc. As an example, the test includes a MATLAB® step in which MATLAB® expressions can be executed. The MATLAB® step communicates with MATLAB® installed locally or in a remote computational device to run the expression and returns the result to thetest manager120. The test steps may also include a Simulink® step to interact with models, and an Instrument Control (one of MATLAB® Toolboxes) step to interact with external hardware. Furthermore, a Statistics Toolbox (one of MATLAB® Toolboxes) step may provide statistical analysis for data procured by other steps. The test steps in the test include discrete actions that are executed during the execution of the test. The test step and test step properties may be deemed a Java function call that generates M-code, and the function call arguments, respectively.
• FIG. 14 is a flow chart showing an exemplary operation for distributing a test in the illustrative embodiment of the present invention. Theclient150 defines a test for testing units under test (step1302). The test may be defined to include one or more test steps. Each test step may test different units under test. Theclient150 then submits at least a portion of the test (step1304) to aninstrument180 orworkstation170 that contains thetechnical computing worker270. For example, theclient150 then submits each test step todifferent workstations170 and/orinstruments180. Thetechnical computing worker270 receives at least a portion of the test (step1306) and performs the requested technical computing as defined by the test (step1308). In performing the technical computing on the test, an associated result may be generated (step1310). In alternative embodiments, either no result is generated, or no result is required to be returned to theclient150. After generating the result from computing the test, theworkstations170 and/orinstruments180 provide the result (step1312) to theclient150, and theclient150 obtains the result from theworkstations170 and/or instruments180 (step1314). One of ordinary skill in the art will appreciate that the distributing operation is illustrative and the test may be distributed by the operations described above with reference toFIGS. 5B-5D. One of ordinary skill in the art will also appreciate that the distribution of the test may be performed in the same way as described above with reference toFIGS. 6A-9B.
• One of ordinary skill in the art will appreciate that theinstrument180 may be used as a technical computing client and/or worker and as an instrumentation tool. In one illustrative embodiment, theinstrument180 may be used as an instrumentation tool performing part of the test that acts on the information collected by theinstrument180. In another embodiment, theinstrument180 may be used as a pure technical computing client or worker utilizing the technical computing functionality of theinstrument180. In still another embodiment, theinstrument180 may be used as both a technical computing client/worker and an instrumentation tool. In this embodiment, theinstrument180 is used as a traditional instrumentation tool when it is needed to make a measurement, and also used as a technical computing client/worker when it is needed to compute at least a portion of the test.
• In some embodiments, if theinstrument180 is used as both a technical computing client/worker and an instrumentation tool, the technical computing functionality and the instrumentation functionality of theinstrument180 may need to be compromised depending on the capability of theinstrument180 to support for both of the functionalities concurrently. One exemplary way to compromise these functionalities is to pause/stop the technical computing functionality when theinstrument180 is needed to make a measurement. When the measurement is completed, theinstrument180 can continue to perform the technical computing functionality. One of ordinary skill in the art will appreciate that this is an exemplary way to compromise the functionalities and the functionalities can be compromised in other ways in different embodiments. The technical computing capability of theinstrument180 can allow users to utilize the additional computational power in theinstrument180 to perform a fast result calculation of a test in the test environment.
• Furthermore, the illustrative embodiment provides for technical programming language constructs to develop program instructions of the jobs and tests to be executed in parallel in multiple technical computing workers. These technical programming language constructs have built-in keywords of the programming language reserved for their functionality. One of these constructs is a distributed array element for technical computing operations executing across multiple technical computing workers. The technical programming language of the parallel technical computing worker of MATLAB® provides reserved key words and built-in language statements to support distributed arrays to check the current process id of the worker.
• In order to provide distributed arrays in a technical computing programming language, an iterator is decomposed into separate iterators for each node or worker that will be processing the distributed array. Each worker is identified by a process id or pid between 1 and the total number of pids, or nproc. For each pid of a worker out of a total numbers of pids, a portion of the distributed array may be processed separately and independently. For example, take the following iterators:
• • var=start:fin
  • or
  • var=start:delta:fin ; where start is the first iteration, fin is the last iteration and delta is the step increments between the first iteration and the last iteration.
    In order to process a portion of the distributed array, an iterator such as the following needs to be decomposed from the standard iterators described above:
  • var=start(pid):delta:fin(pid); where start is the first iteration for the pid, fin is the last iteration for the pid, and delta is the step increments between the first iteration and last iteration for the pid.
    In an exemplary embodiment, an iterator is decomposed into nproc continuous sections of equal or nearly equal iteration lengths. The following is an example algorithm described in the programming language of MATLAB® for determining equal or nearly equal iteration lengths across multiple workers:
  • function [startp,finp]=djays(start,delta,fin,pid,nprocs)
  • ratio=floor((fin-start)/delta+1)/nprocs;
  • startp=start+ceil((pid−1)*ratio)*delta;
  • finp=start+(ceil(pid*ratio)−1)*delta;
    For example, with nproc=4 workers, the iterator j=1:10 is decomposed to the following:
  • j=1:3 on pid=1
  • j=4:5 on pid=2
  • j=6:8 on pid=3
  • j=9:10 on pid=4
• In alterative embodiments, other algorithms can be used to determine the decomposition of iterators and the length of iterators to be applied per pid for processing distributed arrays across multiple workers. For example, the decomposition of the iterator may be determined by estimated processing times for each of the pids for its respective portion of the iterator. Or it may be determined by whichworkers270 are not currently executing a program or whichworkers270 are idle or have not previously executed a program. In another example, only two pids may be used for the iteration although several pids may be available. In yet another example, each iterator may be assigned to a specific worker. In other cases, the decomposition of the iterator can be based on one or more operational characteristics of the worker, or of thecomputing device102 running the worker. One ordinarily skilled in the art will appreciate the various permutations and combinations that can occur in decomposing an iterator to process portions of a distributed array in multiple workers.
• In the parallel technical computing environment of MATLAB®, distributed arrays are denoted with the new keyword darray and in case of distributed random arrays, the new keyword drand. Various alternative names for these keywords, or reserved words could be applied. As keywords or reserved words of the programming language of the parallel technical computing environment, they have special meaning as determined by the worker and therefore are built into the language. As such, these keywords are not available as variable or function names.
• Distributed arrays are distributed by applying the decomposition algorithm to the last dimension of the array. For example, a 1000-by-1000 array is distributed across 10 processors, or workers, by storing the first 100 columns on the first worker, the second 100 columns on the second worker and so forth. The content of a distributed array on a particular worker is the local portion of the array. For example, if A is a distributed array, then A.loc refers to the portion of A on each worker. For example, with nproc=16, the statement
• A=drand(1024,1024) % create a distributed random array becomes
• A=darray(1024,1024)
• A.loc=rand(1000,64)
• Different random submatrices, or arrays, are generated on each one of the sixteen (16) workers. In another embodiment and for the case of a distributed array representing RGB color coding for images with dimensions of m-by-n-by-3, the decomposition and the distribution of the array occurs along the second dimension so that each worker has a full color strip form the overall image to work on in its local portion. Although the distribution of the distributed array is discussed in terms of column based distribution, various alternative methods can be used to distribute portions of the distributed array among multiple workers. For example, the distributed array can be distributed by rows or a portion of rows and columns. In another example, a portion could be distributed based on a subset of the data having all dimensions of the array. Any type of arbitrary mapping can be applied to map a portion of the distributed array to each of the workers. As such, one ordinarily skilled in the art will recognize the various permutation of distributing portions of a distributed array to each worker.
• In another aspect, a distributed array may be cached. That is, an worker may store its portion of the distributed array, e.g., A.loc, but prior to performing operations on the local portion, the worker may still have read access to the other portions of the distributed array. For example, a first worker may be assignedcolumn 1 of a three column distributed array with other two workers assigned columns 2 and 3. The first Worker may have read access to columns 2 and 3 prior to performing operations oncolumn 1 of the array, i.e., read and write access. However, once the first worker performs an operation on its local portion of the distributed array, it may no longer have any access to the other portions of the distributed array. For example, once the first worker performs an operation oncolumn 1, it no longer will have read access to columns 2 and 3 of the distributed array.
• For basic element-wise operations like array addition, each worker may perform the operation on its local portion, e.g., A.loc. No communication between the workers is necessary for the processing of the local portion of the distributed array. More complicated operations, such as matrix transpose, matrix multiplication, and various matrix decompositions, may require communications between the workers. These communications can follow a paradigm that iterates over the workers:

• 	for p = 1:nprocs
  	if p == pid
  	processor p is in charge of this step
  	send data to other processors
  	do local computation
  	maybe receive data from other processors
  	else
  	receive data from p
  	do local computation
  	maybe send data back to p
  	end
  	end

  
  In the above example, the number of communication messages between workers is proportional to the number of workers, and not the size of the distributed array. As such, as arrays get larger the overhead for sending messages to coordinate the array computation becomes proportionately smaller to the array data and the resulting computation time on each worker.
• In one aspect, the present invention relates to methods for programmatically providing for distributed array processing as depicted inFIG. 15. In the flow diagram ofFIG. 15,method1500 depicts the processing of a distributed array in execution in multiple workers. Atstep1502, a worker is executing a program flow of a program (job or test) invoked for execution. At some point during the program flow, theworker270 atstep1504 interprets a distributed array construct in a program statement, such as a program statement comprising the keyword darray. At step506, theworker270 evaluates the distributed array construct to determine the portion of the distributed array to store locally. As discussed above, the distributed array may be decomposed in a variety of ways. For example, theworker270 may store a specific column of the array to perform local processing. After determining and storing the portion of the distributed array, theworker270 may perform an operation on this portion of the array. For example, it may perform basic array operations such as addition. After handling the distributed array statement, the program flow continues to other program statements of the program. In another embodiment, prior to performing an operation on the local portion of the array, theworker270 may access or obtain data values of other portions of the array that have been cached. Althoughmethod1500 is discussed with regards to one worker, the same flow diagram will apply tomultiple workers270 running the same program so that atsteps1504,1506 and1508 the worker interpreting the distributed array determines what portion of the array to store and process locally.
• Many alterations and modifications may be made by those having ordinary skill in the art without departing from the spirit and scope of the invention. Therefore, it must be expressly understood that the illustrated embodiments have been shown only for the purposes of example and should not be taken as limiting the invention, which is defined by the following claims. These claims are to be read as including what they set forth literally and also those equivalent elements which are insubstantially different, even though not identical in other respects to what is shown and described in the above illustrations.

Claims (42)

1. A method for executing a technical computing job in a distributed fashion in an instrument-based distributed computing system, the method comprising:

providing, using a technical computing client, a technical computing job, the technical computing client being a first instrument;

distributing the technical computing job to a plurality of technical computing workers, the plurality of technical computing workers including a first technical computing worker and a second technical computing worker, the distributing comprising:

sending a first portion of the technical computing job to the first technical computing worker for execution, and

sending a second portion of the technical computing job to the second technical computing worker for execution; and

receiving a first execution result from the first technical computing worker and a second execution result from the second technical computing worker.

2. The method ofclaim 1, wherein at least one of the plurality of technical computing workers is a second instrument.

3. The method ofclaim 2, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

4. The method ofclaim 2, wherein the second instrument comprises test equipment and the technical computing job comprises a test for testing a unit under test.

5. The method ofclaim 4, wherein the test equipment accelerates execution of a measurement, analysis, verification or validation of the test.

6. The method ofclaim 4, wherein the test includes one or more test steps for testing a textual program, a graphical program a function provided in a software tool, or a hardware device.

7. The method ofclaim 1, wherein the first instrument includes technical computing functionality and an instrumentation functionality for making a measurement.

8. The method ofclaim 1, further comprising:

providing a local area network interface for the first instrument, the local area network interface allowing the first instrument to communicate with the plurality of technical computing workers over the local area network.

9. The method ofclaim 1, wherein the distributing comprises:

sending the first portion of the technical computing job to the first technical computing worker using a distributed array, and

sending the second portion of the technical computing job to the second technical computing using the distributed array.

10. The method ofclaim 9, wherein the first technical computing worker or the second technical computing worker performs an operation on the portion of the distributed array.

11. The method ofclaim 1, wherein the second instrument performs technical computations using a graphics processing unit (GPU).

12. A method for executing a technical computing job in a distributed fashion in an instrument-based distributed computing system, the method comprising:

receiving, using a technical computing worker, a portion of a technical computing job, the technical computing worker being a first instrument;

executing the received portion of the technical computing job, the executing generating an execution result; and

sending the execution result to a technical computing client.

13. The method ofclaim 12, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

14. The method ofclaim 12, further comprising:

providing a local area network interface for the first instrument, the local area network interface allowing the first instrument to communicate with the technical computing client over the local area network.

15. The method ofclaim 12, wherein the first instrument performs technical computations for executing the received portion of the technical computing job using a graphics processing unit (GPU).

16. The method ofclaim 12, wherein the technical computing client is a second instrument.

17. The method ofclaim 16, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

18. The method ofclaim 12, wherein the first instrument comprises test equipment and the technical computing job comprises a test for testing a unit under test.

19. The method ofclaim 18, wherein the test equipment accelerates execution of a measurement, analysis, verification or validation of the test.

20. The method ofclaim 18, wherein the test includes one or more test steps for testing a textual program, a graphical program a function provided in a software tool or a hardware device.

21. A non-transitory storage medium storing instructions executable in an electronic instrument for executing a technical computing job in a distributed fashion in an instrument-based distributed computing system, the medium storing one or more instructions for:

providing, using a technical computing client, a technical computing job, the technical computing client being a first instrument;

distributing the technical computing job to a plurality of technical computing workers, the plurality of technical computing workers including a first technical computing worker and a second technical computing worker, the distributing comprising:

sending a first portion of the technical computing job to the first technical computing worker for execution, and

sending a second portion of the technical computing job to the second technical computing worker for execution; and

receiving a first execution result from the first technical computing worker and a second execution result from the second technical computing worker.

22. The non-transitory medium ofclaim 21, wherein at least one of the plurality of technical computing workers is a second instrument.

23. The non-transitory medium ofclaim 22, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

24. The non-transitory medium ofclaim 22, wherein the second instrument comprises test equipment and the technical computing job comprises a test for testing a unit under test.

25. The non-transitory medium ofclaim 24, wherein the test equipment accelerates a measurement, analysis, verification or validation of the test.

26. The non-transitory medium ofclaim 24, wherein the test includes one or more test steps for testing a textual program, a graphical program a function provided in a software tool or a hardware device.

27. The non-transitory medium ofclaim 21, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

28. The non-transitory medium ofclaim 21, further storing one or more instructions for:

providing a local area network interface for the first instrument, the local area network interface allowing the first instrument to communicate with the plurality of technical computing workers over the local area network.

29. The non-transitory medium ofclaim 21, wherein the one or more instructions of distributing comprises one or more instructions for:

sending the first portion of the technical computing job to the first technical computing worker using a distributed array, and

sending the second portion of the technical computing job to the second technical computing worker using the distributed array.

30. The non-transitory medium ofclaim 29, wherein the first technical computing worker or the second technical computing worker performs an operation on the portion of the distributed array.

31. The non-transitory medium ofclaim 21, wherein the second instrument performs technical computations using a graphics processing unit (GPU).

32. A non-transitory storage medium storing instructions executable in an electronic instrument for executing a technical computing job in a distributed fashion in an instrument-based distributed computing system, the medium storing one or more instructions for:

receiving, using a technical computing worker, a portion of a technical computing job, the technical computing worker being a first instrument;

executing the received portion of the technical computing job, the executing generating an execution result; and

sending the execution result to a technical computing client.

33. The non-transitory medium ofclaim 32, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

34. The non-transitory medium ofclaim 32, further storing one or more instructions for:

providing a local area network interface for the first instrument, the local area network interface allowing the first instrument to communicate with the technical computing client over the local area network.

35. The non-transitory medium ofclaim 32 wherein the first instrument performs technical computations for executing the received portion of the technical computing job using a graphics processing unit (GPU).

36. The non-transitory medium ofclaim 32, wherein the technical computing client is a second instrument.

37. The non-transitory medium ofclaim 36, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.

38. The non-transitory medium ofclaim 32, wherein the first instrument comprises test equipment and the technical computing job comprises a test for testing a unit under test.

39. The non-transitory medium ofclaim 38, wherein the test equipment accelerates a measurement, analysis, verification or validation of the test.

40. The non-transitory medium ofclaim 38, wherein the test includes one or more test steps for testing a textual program, a graphical program a function provided in a software tool or a hardware device.

41. An instrument for executing at least a portion of a technical computing job in a distributed fashion, the instrument comprising:

a processor for:

receiving at least a portion of the technical computing job from a technical computing client,

executing the received portion of the technical computing job, the executing generating an execution result, and

sending the execution result to the technical computing client over a network.

42. An instrument for processing a technical computing job in a distributed fashion, the instrument comprising:

a processor for:

providing the technical computing job,

sending a first portion of the technical computing job to a first technical computing worker for execution,

sending a second portion of the technical computing job to a second technical computing worker for execution; and

receiving a first execution result from the first technical computing worker and a second execution result from the second technical computing worker.

Images