US20110167425A1 - Instrument-based distributed computing systems - Google Patents

Instrument-based distributed computing systems Download PDF

Info

Publication number
US20110167425A1
US20110167425A1 US13/045,243 US201113045243A US2011167425A1 US 20110167425 A1 US20110167425 A1 US 20110167425A1 US 201113045243 A US201113045243 A US 201113045243A US 2011167425 A1 US2011167425 A1 US 2011167425A1
Authority
US
United States
Prior art keywords
technical computing
job
instrument
worker
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/045,243
Inventor
Roy Lurie
Thomas Gaudette
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MathWorks Inc
Original Assignee
MathWorks Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MathWorks Inc filed Critical MathWorks Inc
Priority to US13/045,243 priority Critical patent/US20110167425A1/en
Assigned to THE MATHWORKS, INC. reassignment THE MATHWORKS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GAUDETTE, THOMAS, LURIE, ROY
Publication of US20110167425A1 publication Critical patent/US20110167425A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5072Grid computing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a method 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.
  • a method 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.
  • a system 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.
  • a medium holding instructions executable in an instrument 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.
  • a medium holding instructions executable in an instrument 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.
  • 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 of FIG. 3A ;
  • FIG. 5B is a flow diagram of steps performed in an embodiment of FIG. 3B ;
  • FIG. 5C and FIG. 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 in FIG. 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 in FIG. 13 ;
  • FIG. 15 is a flow chart showing an exemplary operation for providing a distributed array in the illustrative embodiment of the present 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.
  • 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.
  • the instrument may include hardware components, such as FPGA, ASIC, DSP and CPU, to perform fast calculations, such as FFT calculations.
  • 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.
  • 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.
  • 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.
  • 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 MapleTM 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.
  • 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.
  • 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 a computing device 102 having memory 106 , on which software according to one embodiment of the present invention may be stored, a processor (CPU) 104 for executing software stored in the memory 106 , and other programs for controlling system hardware.
  • the memory 106 may comprise a computer system memory or random access memory such as DRAM, SRAM, EDO RAM, etc.
  • the memory 106 may comprise other types of memory as well, or combinations thereof.
  • a human user may interact with the computing device 102 through a visual display device 114 such as a computer monitor, which may include a graphical user interface (GUI).
  • GUI graphical user interface
  • the computing device 102 may include other I/O devices such a keyboard 110 and a pointing device 112 , for example a mouse, for receiving input from a user.
  • the keyboard 110 and the pointing device 112 may be connected to the visual display device 114 .
  • the computing device 102 may include other suitable conventional I/O peripherals.
  • the computing device 102 may support any suitable installation medium 116 , 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 distributed computing application 120 .
  • the computing device 102 may further comprise a storage device 108 , 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 distributed computing application 120 of an embodiment of the present invention. Additionally, the operating system and the MATLAB®-based distributed computing application 120 of the present invention can be run from a bootable CD, such as, for example, KNOPPIX®, a bootable CD for GNU/Linux.
  • a bootable CD such as, for example, KNOPPIX®, a bootable CD for GNU/Linux.
  • the computing device 102 may include a network interface 118 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.
  • the network interface 118 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 the computing device 118 to any type of network capable of communication and performing the operations described herein.
  • the computing device 102 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 distributed computing application 120 of an embodiment of the present invention running in a stand-alone system configuration of a single computing device 102 .
  • FIG. 1B depicts another environment suitable for practicing an illustrative embodiment of the present invention, where functionality of the MATLAB®-based distributed computing application 120 is distributed across multiple computing devices ( 102 ′, 102 ′′ and 102 ′′′).
  • the system 100 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.
  • the system 100 includes a client 150 (e.g., a first computing device 102 ′) in communications through a network communication channel 130 with a server computer 160 , also known as a server, (e.g., a second computing device 102 ′′) over a network 140 and the server in communications through a network communications channel 130 with a workstation (e.g., a third computing device 102 ′′′) over the network 140 ′.
  • a client 150 e.g., a first computing device 102 ′
  • server computer 160 also known as a server
  • a workstation e.g., a third computing device 102 ′′′
  • the client 150 , the server 160 , and the workstation 170 can be connected 130 to the networks 140 and/or 140 ′ 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 the client 150 , server 160 and workstation 170 can be any type of computing device ( 102 ′, 102 ′′ and 102 ′′′) as described above and respectively configured to be capable of computing and communicating the operations described herein.
  • each of the client 150 , server 160 and workstation 170 are configured to and capable of running at least a portion of the present invention of the MATLAB®-based distributed computing application 120 .
  • the MATLAB®-based distributed computing application has one or more software components that run on each of the client 150 , server 160 and workstation 170 , respectively, and work in communication and in collaboration with each other to meet the functionality of the overall application.
  • the client 150 may hold a graphical modeling environment that is capable of specifying block diagram models and technical computing tasks to analyze the model.
  • the client 150 may have software components configured to and capable of submitting the tasks to the server 160 .
  • the server 160 may have software components configured to and capable of receiving the tasks submitted by the client 150 and for determining a workstation 170 to assign the task for technical computing.
  • the workstation 170 may hold software components capable of providing a technical computing environment to perform technical computing of the tasks assigned from the server 160 and submitted by the client 150 .
  • the technical computing environment and software components of the MATLAB®-based distributed computing application 120 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 distributed computing application 120 .
  • the system 200 of the MATLAB®-based distributed computing application 120 is a two-node distributed system comprising a technical computing client application 250 , or technical computing client, running on a client 150 computer and a technical computing worker application 270 , or technical computing worker, running on a workstation 170 .
  • the technical computing client 250 is in communications with the technical computing worker 270 through a network communications channel 130 over a network 140 .
  • the technical computing client 250 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.
  • the technical computing client 250 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, the technical computing client 250 can be any of the software programs available in the MATLAB® product family. Furthermore, the technical computing client 250 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.
  • an interface such as an application programming interface
  • functions can be defined representing a technical computing task to be executed by either a technical computing environment local to the client computer 150 , or remote on the workstation 270 .
  • the local technical computing environment may be part of the technical computing client 250 , or a technical computing worker running on the client computer 150 .
  • 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 the technical computing worker 270 on the workstation 170 , or alternatively, on the client 150 .
  • the technical computing client 250 may declare a function to generate a random set of ten numbers and further delegate that the technical computing worker 270 running on the workstation 170 execute the function.
  • the application programming interface and programming language of the MATLAB®-based client 250 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.
  • the technical computing client 250 may declare a variable to hold a result returned from the technical computing worker 270 performing technical computing of the random generation function.
  • the distributed functionality features of the programming languages of the MATLAB®-based client 250 allows the technical computing client 250 to use the computing resources that may be available from a technical computing worker 270 on the workstation 170 to perform technical computing of the task. This frees up the technical computing client 250 to perform other tasks, or the client computer 150 to execute other software applications.
  • the technical computing worker 270 of the system 200 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 the technical computing client 250 .
  • the technical computing worker 270 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 running technical computing worker 270 by which a technical computing client can connect and access its functionality.
  • the technical computing worker 270 can include all the functionality and software components of the technical computing client 250 , or it can just include those software components it may need to perform technical computing of tasks it receives for execution.
  • the technical computing worker 270 may be configured to and capable of running any of the modules, libraries or software components of the MATLAB® product family. As such, the technical computing worker 270 may have all or a portion of the software components of MATLAB® installed on the workstation 170 , or alternatively, accessible on another system in the network 140 .
  • the technical computing worker 270 has mechanisms, described in detail later, to receive a task distributed from the technical computing client 250 .
  • the technical computing worker 270 is capable of performing technical computing of the task as if the technical computing client 250 was performing the technical computing in its own technical computing environment.
  • the technical computing worker 270 also has mechanisms, to return a result generated by the technical computing of the task to the technical computing client 250 .
  • the technical computing worker 270 can be available on an as needed basis to the technical computing client 250 .
  • the workstation 170 of the technical computing worker 270 can be executing other software programs, or the technical computing worker 270 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 in FIG. 2B .
  • the multi-tier distributed system 205 includes a technical computing client 250 running on a client computer 150 in communications over a network communication channel 130 to a server 160 on a network 140 .
  • the server 160 comprises an automatic task distribution mechanism 260 and a job manager 265 .
  • the job manager 265 interfaces with the automatic task distribution mechanism 260 on the server 160 .
  • the automatic task distribution mechanism 260 communicates over a network communication channel 130 on the network 140 to the technical computing worker 270 on the workstation 170 .
  • the automatic task distribution mechanism 260 comprises one or more application software components to provide for the automatic distribution of tasks from the technical computing client 250 to the technical computing worker 270 .
  • the automatic task distribution mechanism 260 allows the technical computing client 250 to delegate the management of task distribution to the automatic task distribution mechanism 260 .
  • a task can be defined and submitted to the automatic task distribution mechanism 260 without specifying which technical computing worker 270 is to perform the technical computing of the task.
  • the technical computing client 250 does not need to know the specifics of the technical computing worker 270 .
  • the technical computing client can define a function to submit the task to the automatic task distribution mechanism 260 , and get a result of the task from the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism provides a level of indirection between the technical computing client 250 and the technical computing worker 270 .
  • the technical computing client 250 does not need to have prior knowledge of the availability of the technical computing worker 270 .
  • the automatic task distribution mechanism 260 can manage and handle the delegations of the tasks to the same technical computing worker 270 , or to other technical computing workers and hold the results of the tasks on behalf of the technical computing client 250 for retrieval after the completion of technical computing of all the distributed tasks.
  • a job manager module 265 is included as an interface to the task and result management functionality of the automatic task distribution mechanism 260 .
  • the job manager 265 can comprise an object-oriented interface to provide control of delegating tasks and obtaining results in the multi-tiered distributed system 205 .
  • the job manager 265 provides a level of programming and integration abstraction above the details of inter-process communications and workflow between the automatic task distribution mechanism 260 and the technical computing worker 270 .
  • the job manager 265 also provides an interface for managing a group of tasks collectively as a single unit called a job, and on behalf of a technical computing client 250 , submitting those tasks making up the job, and obtaining the results of each of the tasks until the job is completed.
  • the automatic task distribution mechanism 260 can include the functionality and object-oriented interface of the job manager 265 , or the automatic task distribution mechanism 260 and the job manager 265 can be combined into a single application, or software component.
  • the job manager 265 comprises both the functionality of the job manager 265 and the automatic task distribution mechanism 260 .
  • One ordinarily skilled in the art will recognize the functions and operations of the job manager 265 and the automatic task distribution mechanism 260 can be combined in various software components, applications and interfaces.
  • FIG. 2C an exemplary embodiment of the present invention is shown with multiple technical computing workers 270 A- 270 N hosted on a plurality of workstations 170 A- 170 N.
  • the technical computing client 250 may be in communication through the network communication channel 130 on the network 140 with one, some or all of the technical computing workers 270 A- 270 N.
  • the automatic task distribution mechanism 260 may be in communication through the network communication channel 130 on the network 140 with one, some or all of the technical computing workers 270 A- 270 N.
  • the technical computing client 250 and/or the automatic task distribution mechanism 260 can distribute tasks to multiple technical computing workers 270 A- 270 N to scale the distributed system and increase computation time of tasks.
  • the technical computing workers 270 A- 270 B can be hosted on the same workstation 170 A, or a single technical computing worker 270 C can have a dedicated workstation 170 B.
  • one or more of the technical computing workers 270 A- 270 N can be hosted on either the client 150 or the server 160 .
  • the computing devices ( 102 , 102 ′, 102 ′′, 102 ′′′) depicted in FIGS. 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.
  • 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.
  • 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 ′′′).
  • each of the client 150 , the server 160 and the workstation 170 can be running the same or different operating systems.
  • the client 150 can running Microsoft® Windows
  • the server 160 can be running a version of Unix
  • the workstation a version of Linux.
  • each of the client 150 , the server 160 and the workstation 170 can be running Microsoft® Windows.
  • 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 ′′′).
  • the software components of the MATLAB®-based distributed computing environment can run on a 32 bit processor of one computing device 102 and a 64 bit processor of another computing device 102 ′.
  • 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 ′′, and 102 ′′′).
  • any other system and/or deployment architecture that combines and/or distributes one or more of the technical computing client 250 , job manager 265 , automatic task distribution mechanism 260 and technical computing worker 270 across any other computing devices and operating systems available in the network 140 may be used.
  • all the software components of the MATLAB®-based distributed computing application can run on a single computing device 102 , such as the client 150 , server 160 or the workstation 170 .
  • FIGS. 3A , 3 B and 3 C 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
  • FIG. 3C a batch mode of automated distribution.
  • FIG. 3D depicts an exemplary embodiment of the batch mode of automated distribution.
  • the direct distribution system 305 of FIG. 3A is intended for those users who desire a high level of control over which technical computing worker 270 A- 270 N executes a particular task.
  • the technical computing client 250 is in communications with a plurality of technical computing workers, 270 A- 270 N, each running on their own workstation 170 A- 170 N.
  • one or more of these technical computing workers 270 A- 270 N can be running on the same computing device, e.g., workstation 270 A, or on the client 150 or the server 160 .
  • This direct distribution system 305 allows a task to be sent to a particular technical computing worker, e.g., technical computing worker 270 A of a plurality of technical computing workers 270 A- 270 N. Then, the technical computing client 250 can continue with other work while the specified technical computing worker, e.g., technical computing worker 270 A, is performing technical computing of the submitted task. Some time after submitting the task to the technical computing worker 270 A, the technical computing client 250 can then obtain the result of the task from the technical computing worker 270 A. Furthermore, each technical computing worker 270 N can process multiple tasks, e.g., TaskN-M, and for each task produce a result, e.g., ResultN-M.
  • the technical computing worker 270 A 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 known workstations 170 A- 170 N and technical computing workers 270 A- 270 N.
  • a task can be delegated to a specified technical computing worker running 270 A on a workstation 170 A that has a higher speed configuration than the other workstations 170 B- 170 N. For example, a longer task could be executed on such a workstation 170 A in order to speed the overall computation time.
  • the technical computing client 250 of the direct distribution system 305 can submit multiple tasks (e.g., TaskN-M) to each of the multiple technical computing workers 270 A- 270 N.
  • TaskN-M multiple tasks
  • the technical computing client 250 submits task 1 to technical computing worker 270 A, submits task 2 to technical computing worker 270 B, and submits task N to technical computing worker 270 N.
  • the technical computing client 250 can submit task 1 , task 2 and taskN-M one immediately after another or within a certain time between each other.
  • the technical computing workers 270 A- 270 N can be performing technical computing of their respective tasks independently and in parallel to each other.
  • the technical computing workers 270 A- 270 N may perform technical computing of their respective task while the other technical computing workers are idle.
  • the technical computing workers 270 A- 270 N may include interfaces and communication channels to interact with each other as depicted by the phantom arrowed lines between the technical computing workers 270 A- 270 N in FIG. 3A .
  • technical computing worker 270 A may perform a portion of technical computing on task 1 , and then submit task 1 , and optionally, any generated result or other data, for further technical computing by technical computing worker 270 B.
  • the technical computing worker 270 A may also submit the result of its technical computing of task 1 to the technical computing client 250 , before or after, submitting the task to technical computing worker 270 B for further processing.
  • Technical computing worker 270 B may in turn perform technical computing of task 1 , and subsequently submit task 1 for further processing by technical computing worker 270 N.
  • the technical computing workers 270 A- 270 N can obtain information with the task about the identification of other technical computing workers 270 A- 270 N in the system. This information would be used to communicate and interact with another technical computing worker.
  • a technical computing worker 270 A may find another technical computing worker 270 B- 270 N by making a function or system call, or a method call to a service provider on the network 140 .
  • technical computing workers 270 A- 270 N can either execute tasks independently and in parallel to each other, or also execute tasks serially and subsequent to each other.
  • the automated task distribution mode embodied in system 310 is intended to provide a configuration where the user does not want to control which technical computing worker 270 A- 270 N executes a particular task.
  • a technical computing client 250 is in communication with the automatic task distribution mechanism 260 running on the server 160 .
  • the automatic task distribution mechanism 260 is in communications with a plurality of technical computing workers 270 A- 270 N.
  • the technical computing client 250 is not required to have any specific knowledge of the technical computing workers 270 A- 270 N, e.g., the name of the workstation running a technical computing worker 270 A- 270 N, or the availability of the technical computing worker 270 A- 270 N to perform technical computing of a task. In alternative embodiments, it may have prior knowledge of all or a portion of the technical computing workers 270 A- 270 N available on the network. Even with knowledge of the name or availability of technical computing workers 270 A- 270 N on the network 140 , the technical computing client 250 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 available technical computing worker 270 A- 270 N.
  • the technical computing client 250 submits one or more tasks (Task 1 -TaskN-M) to the automatic task distribution mechanism 260 . These tasks can be submitted sequentially or in an order and frequency as specified by the technical computing client 250 .
  • the automatic task distribution mechanism 260 obtains the tasks (Task 1 -TaskN-M) to make then available for distribution to any of the technical computing workers 270 A- 270 N.
  • a technical computing worker 270 A- 270 N takes a task from the automatic task distribution mechanism 260 for technical computing of the task, computes a result for the task and provides the result to the automatic task distribution mechanism 260 .
  • technical computing worker 270 A takes task 1 from the automatic task distribution mechanism 260 , computes a result, Result 1 , for task 1 , and submits Result 1 to the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism 260 makes the results (Result 1 -ResultN-M) available to the technical computing client 250 as they get submitted from the technical computing worker 270 A- 270 N generating and submitting the respective result.
  • the technical computing client 250 obtains the results of the computed tasks from the automatic task distribution mechanism 260 .
  • the technical computing client 250 may obtain all the results (Result 1 -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 automatic task distribution mechanism 260 . Accordingly, the technical computing client 250 can determine the order and frequency of obtaining one or more of the results. As with the direct distribution mode, the technical computing workers 270 A- 270 N can also communicate and interact with each other, as depicted by the phantom arrowed lines between the technical computing workers 270 A- 270 N in FIG. 3B , to execute tasks both serially and in parallel by submitting a task to another technical computing worker 270 A- 270 N.
  • the batch mode of automated task distribution embodied in system 315 of FIG. 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 automatic task distribution mechanism 260 .
  • a technical computing client 250 is in communication with the job manager 265 on the server 160 .
  • the job manager 265 interfaces and communicates with the automatic task distribution mechanism 260 running on the same server 160 .
  • Each of the technical computing workers 270 A- 270 N is in communication with the automatic task distribution mechanism 260 .
  • a job manager 265 interfaces with and is associated with one automatic task distribution mechanism 260 .
  • the job manager 265 and the automatic task distribution mechanism could be on different servers 160 .
  • a plurality of job managers and automatic task distribution mechanisms could be running on a single server 160 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 the job manager 265 and the automatic distribution mechanism 260 to handle additional multiple technical computing clients 250 distributing tasks.
  • the technical computing client 250 defines the job.
  • the technical computing client 250 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 in FIG. 3B , the technical computing client 250 submits the job containing all the associated tasks to the job manager 265 .
  • the job manager 265 is a software component that provides an object-oriented interface to the automatic task distribution mechanism 260 .
  • the job manager 265 obtains the tasks from the job and provides the tasks to the automatic task distribution mechanism 260 for technical computing workers 270 A- 270 N to take and compute results.
  • technical computing client 250 defines a job, Job 1 , with a set of three tasks: Task 1 , Task 2 and TaskN-M.
  • the technical computing client 250 then submits Job 1 to the job manager 265 .
  • the job manager 265 obtains Job 1 and obtains each of the tasks, Task 1 -TaskN-M from Job 1 .
  • the job manager 265 submits each of the tasks to the automatic task distribution mechanism 260 for technical computing by a technical computing worker 270 A- 270 N.
  • Technical computing worker 270 A may take Task 1 from the automatic task distribution mechanism 260 , compute a Result 1 for Task 1 and provide the Result 1 to the automatic task distribution mechanism 260 .
  • Technical computing worker 270 B and technical computing worker 270 N compute and provide results for Task 2 and TaskN-M respectively.
  • the job manager 265 then obtains the set of results for the completed job of Job 1 and provides the results of each of the tasks to the technical computing client 250 .
  • the job manager 265 further comprises a queue 267 for arranging and handling submitted jobs.
  • the job manager 265 may handle jobs in a first-in first-out (FIFO) manner. In this case, the job manager 265 does not process the next job until all the tasks from the current job have been processed by the automatic task distribution mechanism 260 .
  • the job manager 265 using the queue 267 supports handling multiple job submissions and task distribution from multiple technical computing clients 250 . If a first technical computing client 250 submits a job, Job 1 , the job manager 265 places that job first in the queue 267 . If a second technical computing client submits a second Job, for example, Job 2 , the job manager places the job in the queue behind the Job 1 from the first client.
  • the job manager 265 could implement a variety of algorithms for processing jobs in a job queue 267 and for handling multiple technical computing clients 250 .
  • a user may be able to specify a priority level for a specified job, or the logic of the job manager 265 may make task distributing and processing decisions based on the configuration and availability of technical computing workers 270 A- 270 B to determine a preferred or optimal selection of technical computing of jobs and tasks.
  • the technical computing workers 270 A- 270 N in batch mode can also communicate and interact with each other as shown by the phantom arrowed lines between technical computing workers 270 A- 270 N in FIG. 3C .
  • This allows the technical computing workers 270 A- 270 N to execute tasks both serially and in parallel by submitting a task to another technical computing worker.
  • a technical computing worker 270 A can obtain information about the other technical computing workers 270 B- 270 N assigned to or working on tasks associated with a specific job, or available on the network 140 .
  • the exemplary embodiment of the batch mode of automated task distribution system 320 of FIG. 3D depicts a configuration where the job manager 265 contains the automatic task distribution mechanism 260 .
  • a technical computing client 250 is in communication with the job manager 265 on the server 160 .
  • the job manager 265 comprises a task distribution mechanism 260 running as part of the job manager 265 on the same server 160 .
  • the job manager 265 further comprises a queue 267 for arranging and handling submitted jobs.
  • the technical computing workers 270 A- 270 N are in communication with the job manager 265 to receive tasks from the automatic task distribution mechanism 260 of the job manager 265 .
  • the technical computing client 250 defines the job comprised of related tasks. Instead of submitting each task separately as depicted in FIG. 3B , the technical computing client 250 submits the job containing all the related tasks to the job manager 265 .
  • the job manager 265 obtains the tasks from the job and submits the tasks, via an automatic task distribution mechanism 260 , to the technical computing workers 270 A- 270 N to perform technical computing.
  • technical computing client 250 defines a job, Job 1 , with a set of three tasks: Task 1 , Task 2 and TaskN-M. The technical computing client 250 then submits Job 1 to the job manager 265 .
  • the job manager 265 obtains Job 1 and obtains each of the tasks, Task 1 -TaskN-M, from Job 1 . Then, the automatic task distribution mechanism 260 of the job manager 265 submits each of the tasks to a technical computing worker 270 A- 270 N for technical computing. For example, the job manager 265 may submit Task 1 to technical computing worker 270 A to compute and produce a Result 1 for Task 1 . Technical computing worker 270 A provides the Result 1 to the job manager 265 . In a similar fashion, the job manager 265 may submit Task 2 and TaskN-M to technical computing worker 270 B and technical computing worker 270 N with each technical computing worker 270 A and 270 B providing the results for Task 2 and TaskN-M respectively to the job manager 265 . When all the results from each of the tasks of Job 1 are received, the job manager 265 then provides the results of each of the tasks of Job 1 to the technical computing client 250 .
  • the job manager 265 or automatic task distribution mechanism 260 can be configured to define the minimum and maximum numbers of technical computing workers 270 A- 270 N 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 the job manager 265 or automatic task distribution mechanism 260 , 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 or 320 ) can compare the number of technical computing workers 270 A- 270 N registered, or otherwise available, with the job manager 265 or automatic task distribution mechanism 260 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 of technical computing workers 270 A- 270 N registered or available to work on the job.
  • the system can check the number of available or registered technical computing workers 270 A- 270 N 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 of technical computing workers 270 A- 270 N.
  • 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.
  • the system may only start the job if the minimum number of technical computing workers 270 A- 270 A are available or registered to start the job, and may not use any more technical computing workers 270 A- 270 N 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 separate technical computing workers 270 A- 270 N. For example, a job may have 5 tasks and the minimum and maximum technical computing worker settings may be set to 5.
  • the system can determine or select the technical computer worker 270 A- 270 N to work on a task by operational and/or performance characteristics of the technical computing worker 270 A- 270 N and/or workstation 170 A- 170 N.
  • a technical computing worker 270 A may work on a task based on the version of the MATLAB®-based distributed computing application that is installed on the workstation 170 A or that the technical computing worker 270 A is capable of running.
  • the technical computing worker 270 A- 270 N and workstation 170 A- 170 N 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 that specific computing device 102 of the workstation 170 A.
  • 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 the technical computing worker 270 A- 270 N. Furthermore, the system may determine the technical computing worker 270 A- 270 N to work on a task by any configuration or properties set on the technical computing worker 270 A- 270 N or workstation 170 A- 170 N.
  • the system may discover any configuration, properties, and operational and performance characteristics of the MATLAB®-based distributed computing application of a technical computing worker 270 A- 270 N running on a workstation 170 A- 170 N through any interface of the technical computing worker 270 A-N or workstation 170 A- 170 N, such as, for example, in a file, graphical user interface, command or message.
  • FIG. 4 is an illustrative embodiment of the present invention showing the distributed application performing, concurrently, the combination of the modes of operation depicted in FIGS. 3A-3C .
  • the distributed system 400 is depicted supporting multiple clients 250 A- 250 N communicating with multiple job managers 265 A- 265 N and multiple automatic task distribution mechanisms 260 A- 260 N. With these multiple modes of operation, any technical computing client 250 A- 250 N can distribute tasks directly to a technical computing worker 270 A- 270 N, submit tasks to the automatic task distribution mechanism 260 , or submit a job to the job manager 265 .
  • a plurality of technical computing clients 250 A- 250 N are in communication with one or more job managers 265 A- 265 N.
  • the job manager 265 A can be a separate component interfacing to the automatic task distribution mechanism 260 A, or the job manager 265 N can be a single application comprising the functionality of the automatic task distribution mechanism 260 N.
  • the one or more technical computing workers 270 A- 270 B are in communication with the one or more job managers 265 N or the one or more automatic task distribution mechanisms 260 A.
  • 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.
  • a technical computing client 250 A can operate in both the direct distribution mode and the batch automated distribution mode. As such, technical computing client 250 A can submit a task to and receive a result from the automatic task distribution mechanism 260 A without using the job manager 265 A. In another instance, technical computing client 250 A can submit a job, Job 1 , to the job manager 265 A for task distribution by the automatic task distribution mechanism 260 A to receive results from the job, such as Job 1 Results. In another example of FIG. 4 , technical computing client 250 B can operate in batch automated distribution mode but submit jobs separately to a first job manager 265 A running on a first server 160 A and a second job manager 265 N running on a second server 160 N.
  • technical computing client 250 N operates in both the automated distribution and direct distribution modes.
  • Technical computing client 250 N submits a task, Task 2 , to automatic task distribution mechanism 260 N and receives a result, Task 2 Result, from computing by a technical computing worker 270 A- 270 N assigned by the system 400 .
  • Technical computing client 250 N also directly submits a task to technical computing worker 270 N and receives a computed result directly from the technical computing worker 270 N.
  • One ordinarily skilled in the art will appreciate the various combinations of deployments that can occur with such a distributed system 400 with multiple modes of operation. As such, the present invention offers scalability and flexibility for distributed processing of complex technical computing requirements.
  • FIGS. 5A , 5 B and 5 C 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
  • FIG. 5C a batch mode method of automated distribution.
  • Method 500 to distribute a task from a technical computing client 250 to a technical computing worker 270 is illustrated.
  • Method 500 is practiced with the direct distribution embodiment of the invention depicted in FIG. 3A .
  • the technical computing client 250 defines a task comprising an operation for technical computing (step 502 ).
  • 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.
  • the technical computing client 250 then submits the task (step 504 ) to the technical computing worker 270 .
  • the technical computing worker 270 receives the task (step 506 ) and performs the requested technical computing as defined by the task (step 508 ).
  • an associated result may be generated (step 510 ). In alternative embodiments, either no result is generated, or no result is required to be returned to the technical computing client 250 .
  • the technical computing worker 270 After generating the result from computing the task, the technical computing worker 270 provides the result (step 512 ) to the technical computing client 250 , and the technical computing client 250 obtains the result from the technical computing worker 270 (step 514 ).
  • FIGS. 5B an embodiment of the method 525 to distribute a task from a technical computing client 250 to a technical computing worker 270 in automated task distribution mode is illustrated.
  • Method 525 is practiced with the automatic task distribution embodiment of the invention depicted in FIG. 3B .
  • a technical computing worker 270 registers to receive notification of one or more tasks (step 527 ) becoming available, or appearing, in the automatic task distribution mechanism 260 .
  • the technical computing client 250 defines a task comprising an operation for technical computing (step 502 ).
  • the technical computing client 250 then submits the task (step 530 ) to the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism 260 receives the task and makes the task available for distribution (step 532 ) to a technical computing worker 270 .
  • the technical computing client registers (step 534 ) with the automatic task distribution mechanism 260 to receive notification when a result associated with the task submitted in step 530 is available, or appears, in the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism 260 registers the technical computing client 250 for notification when the result appears (step 536 ).
  • the automatic task distribution mechanism 260 provides notification (step 538 ) to the technical computing worker 260 of the availability of the task.
  • the technical computing worker obtains (step 544 ) the task provided (step 540 ) from the automatic task distribution mechanism 260 .
  • the technical computing worker 270 performs the requested technical computing on the function or command as defined by the task (step 508 ).
  • an associated result may be generated (step 510 ). In alternative embodiments, either no result is generated or the result is not required to be returned to the technical computing client 250 .
  • the technical computing worker 270 After generating the result from computing the task (step 510 ), the technical computing worker 270 provides the result (step 512 ) to the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism 260 After obtaining the result from the technical computing worker 250 (step 550 ), the automatic task distribution mechanism 260 notifies (step 552 ) the technical computing client 250 that the result is available.
  • the technical computing client 250 obtains (step 556 ) the result provided (step 558 ) by the automatic task distribution mechanism 260 .
  • Method 560 to distribute a task from a technical computing client 250 to a technical computing worker 270 in a batch mode of operation is illustrated.
  • Method 560 is practiced with the batch mode of the automatic task distribution system (e.g. 315 or 320 ).
  • a technical computing worker 270 registers to receive notification of one or more tasks (step 527 ) becoming available, or appearing, in the automatic task distribution mechanism 260 .
  • the technical computing worker registers to receive a task from the job manager 265 or automatic task distribution mechanism 260 as notification to perform computing on the task.
  • the technical computing client 250 defines one or mores tasks (step 562 ), with one or more of the tasks comprising an operation or function for technical computing.
  • the technical computing client 250 groups one or more tasks of the tasks into a job (step 564 ).
  • the technical computing client 250 then submits the job (step 566 ) to the job manager 265 .
  • the job manager 265 obtains the job (step 568 ) from the technical computing client 250 and provides the one or more tasks of the job (step 570 ) to the automatic task distribution mechanism 260 , which makes the one or more tasks available for distribution (step 572 ) to one or more technical computing workers 270 A- 270 N.
  • the job manager 265 or the automatic task distribution mechanism 260 may submit the one or more tasks to the one or more technical computing workers 270 A- 270 N.
  • the technical computing worker 270 may take the task from the job manager 265 or the automatic task distribution mechanism 260 .
  • the technical computing client 250 registers (step 574 ) a callback function with the job manager 265 .
  • the technical computing client 250 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.
  • the job manager 265 calls this function when the job is completed, i.e., when each of the one or more tasks of the job have been completed.
  • the job manager 265 may register (step 576 ) with the automatic task distribution mechanism 260 to receive notification of the results of the submitted tasks appearing in the automatic task distribution mechanism 260 , or being received from the technical computing worker 270 A- 270 N.
  • the automatic task distribution mechanism 260 registers the notification request of the job manager (step 578 ). Then, the automatic task distribution mechanism 260 provides notification to the technical computing worker 270 of the availability of the task (step 538 ). In an exemplary embodiment, the task is sent, by the job manager 265 to the technical computing worker 270 as notification to perform the task. In response to receiving the notification or the task (step 540 ), the technical computing worker 270 obtains (step 542 ) the task provided (step 540 ) from the automatic task distribution mechanism 260 or the job manager 265 . The technical computing worker 270 performs the requested technical computing on the operation as defined by the task (step 508 ). In performing the technical computing on the task, an associated result may be generated (step 510 ).
  • the technical computing worker 270 After generating the result from computing the task (step 510 ), the technical computing worker 270 provides the result (step 510 ) to the automatic task distribution mechanism 260 or the job manager 265 .
  • the automatic task distribution mechanism 260 After obtaining the result from the technical computing worker 250 (step 550 ), the automatic task distribution mechanism 260 notifies (step 587 ) the job manager 265 that the result is available.
  • the job manager 265 receives the results from the technical computing worker 270 .
  • the job manager 265 obtains the result (step 591 ) provided by (step 593 ) the automatic task distribution mechanism 260 .
  • the job manager 265 will notify the technical computing client 250 that the job is completed via the registered callback function (step 595 ). After triggering the completed job callback function (step 597 ), the technical computing client 250 obtains (step 598 ) the result provided (step 599 ) by the job manager 265 .
  • FIG. 6A shows the details of one embodiment of the automation features of a technical computing client 250 and technical computing worker 270 distributing tasks and results with the automatic task distribution mechanism 260 .
  • the automatic task distribution mechanism 260 may be object-oriented and comprise an object exchange repository 662 , 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 an object exchange repository 662 , 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.
  • an object exchange repository such as one implemented with JavaSpace technology is used to provide a level of indirection between the technical computing client 250 and the technical computing worker 270 with regards to task and result objects.
  • the automatic task distribution mechanism 260 comprising the object exchange repository 662 handles task distribution to technical computing workers 270 A- 270 N registered with the automatic task distribution mechanism 260 .
  • the technical computing client 250 and technical computing worker 270 read and write task and result objects to the object exchange repository 662 .
  • a technical computing client 250 executes a write transaction to write a task object to the object exchange repository 662 of the automatic task distribution mechanism 260 .
  • the task object defines a task for technical computing by a technical computing worker 270 who obtains the task object from the object exchange repository 662 .
  • the technical computing client 250 registers with the object exchange repository 662 to be notified when a result object associated with the submitted task object is available in the object exchange repository 662 . In this way, the technical computing client 250 can listen for the appearance of results for tasks submitted for technical computing processing.
  • a technical computing worker 270 registers with the object exchange repository 662 to be notified when a task object appears in the object exchange repository 662 .
  • the object exchange repository 662 sends a notification to the technical computing worker 270 informing of the task object being available in the object exchange repository 662 .
  • the technical computing worker 270 in response to the notification, performs a take operation on the object exchange repository 662 to retrieve the submitted task object.
  • the take operation removes the task from the object exchange repository 662 .
  • a read operation can be performed to get a copy of the task object without removing it from the object exchange repository 662 .
  • the technical computing work 270 obtains the name and arguments of the function to compute from the data structure of the task object. Then the technical computing worker 270 provides the result from the computation by performing a write operation to write a result object to the object exchange repository 662 .
  • the result object defines within its data structure a result of the computation of the function defined in the task object and performed by the technical computing worker 270 .
  • the write of the result object to the object exchange repository 662 triggers the notification event registered by the technical computing client 250 .
  • the technical computing client 250 listening for the result to appear in the object exchange repository 662 , in response to the notification, performs a take operation, or alternatively a read operation, to obtain the result object associated with the submitted task.
  • the technical computing client 250 then obtains the result information defined within the data structure of the retrieved result object.
  • FIG. 6B depicts the operations of the automatic task distribution mechanism 260 interfacing with a job manager 265 .
  • the job manager 265 is a software component providing a front-end interface to the automatic task distribution mechanism 260 , and in this exemplary embodiment, the JavaSpace object exchange repository 662 .
  • the job manager 265 supports the batch mode of automatic task distribution operation of the invention. Under batch processing, tasks are grouped into a job in the technical computing client 250 and then the job is submitted to the job manager 265 for task distribution and task processing by a technical computing worker 270 .
  • the job manager 265 receives a job from one or more technical computing clients 250 A- 250 N, the job manager 265 places the job into a position in a job queue 267 .
  • the job queue 267 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.
  • the job manager 265 handles jobs in a first-in first-out (FIFO) manner and manages the job queue 267 to first take out the job that was first received by the job manager 265 and placed into the job queue 267 .
  • FIFO first-in first-out
  • the job queue 267 depicted in FIG. 6B is holding the jobs of job 1 , job 2 through jobn.
  • Job 1 is the first submitted job to the job manager 265 and is positioned at the top of the job queue 267 .
  • Job 2 through JobN are the next subsequent jobs in the job queue 267 in order of a FIFO queuing system.
  • Job manager 265 While Job 1 is being processed, the job manager 265 does not start to process the next job, Job 2 , until there are no tasks from the Job 1 remaining to be processed in the object exchange repository 662 .
  • job management implementations may be accomplished using a job queue with different queuing and priority mechanisms.
  • the technical computing client 250 submits a job to the job manager 265 and specifies a callback function with the job manager 265 .
  • the job manager 265 is to call the callback function when the job is completed.
  • the job manager receives the job, e.g., job 1 , and places the job into a job queue 267 .
  • the job manager 265 then obtains the one or more tasks from the first job submitted to the job queue.
  • the job manager 265 writes the task object to the object exchange repository 662 .
  • the job manager 265 registers with the object exchange repository 662 to receive a notification when a result object associated with the task appears in the object exchange repository 662 , also known as a space.
  • the job manager 265 listens and waits for the result to appear in the object exchange repository 662 .
  • a technical computing worker 270 registers with the object exchange repository 662 to receive a notification when a task object appears in the object exchange repository 662 . Then the technical computing worker 270 listens for the appearance of task objects. When the task is submitted to the object exchange repository 662 by the job manager 265 , the technical computing worker 270 receives a notification and takes the task from the object exchange repository 662 by performing a take operation. The technical computing worker 270 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 the technical computing worker 270 submits a result object representing a result of the task to the object exchange repository by performing a write operation.
  • the job manager 265 waiting for the result to appear in the object exchange repository 662 receives a notification from the object exchange repository 662 that the result is available.
  • the job manager 265 checks to see if this is the last result to be obtained from the object exchange repository 662 for the job currently being processed. If the result is the last result, the job manager 265 then notifies the technical computing client 250 that the job is completed by calling the registered callback function. In response to executing the callback function, the technical computing client 250 then interfaces with the job manager 265 to retrieve the results from the job manager 265 , which the job manager 265 retrieves from the object exchange repository 662 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.
  • the job manager 265 includes the functionality of the automatic task distribution mechanism 260 .
  • the technical computing client 250 is in communication with the job manager 265 , which is in communication with the technical computing worker 270 .
  • the job manager comprises a job queue 267 , an automatic task distribution mechanism 260 , a job runner 667 , a worker pool 668 and a database 669 .
  • Any of these components of the job manager 265 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.
  • the worker pool 668 contains a list of technical computing workers 270 A- 270 N that are available to work on a task. These technical computing workers 270 A- 270 N may on startup register with a job manager 265 .
  • the name of the job manager 265 the technical computing worker 270 A- 270 N is associated with may be configurable by an interface of the technical computing worker 270 A- 270 N, or by a command line startup parameter, or an external configuration or registration file.
  • the worker pool 668 may keep a list of “good” technical computing workers 270 A- 270 N, or those workers to which the job manager 265 can communicate with and can determine has such a status to be available for processing tasks.
  • the job manager 265 can update the worker pool 667 by going through the list of technical computing workers 270 A- 270 N registered in the worker pool 667 and sending communications to each of the technical computing workers 270 A- 270 N to determine their status and if they are available. Accordingly, the worker pool 667 can be updated to determine the current set of technical computing workers 667 available, or otherwise able to receive tasks from the job manager 265 .
  • the job runner 667 is responsible for determining the next task to work on and for submitting the task to a technical computing worker 270 A- 270 N.
  • the job runner 667 works with the job queue 267 and takes the next task for processing from a job in the job queue 267 .
  • the job runner 667 obtains from the worker pool 668 a name of or reference to a technical computing worker 270 A- 270 N and submits the task for processing to the obtained technical computing worker 270 A- 270 N.
  • the job runner 667 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 the job queue 267 or any other manner based on priority, availability, task and job option settings, user configuration, etc.
  • the job runner 667 in conjunction with the worker pool 668 and the job queue 267 can form a portion of or all of the functionality of the automatic task distribution mechanism 260 .
  • the job runner 667 can have such logic to determine from the worker pool 668 which technical computing worker 270 A- 270 N should be assigned and sent a task from the job queue 267 .
  • a separate automatic task distribution mechanism 260 can be responsible for determining the technical computing worker 270 A- 270 N to be assigned a task and to send the task to the assigned technical computing worker 270 A- 270 N.
  • the technical computing worker 250 does not need to know the identity, such as via a hostname or an internet protocol address, of the technical computing worker 270 A- 270 N assigned to perform technical computing on a task.
  • the job manager 265 also has a database 669 for storing and retrieving job manager, job and task objects and data, or other objects and data to support the operations described herein.
  • jobs in the job queue 267 the list of workers of the worker pool 668 , the tasks of any jobs in the job queue 267 , the properties of any of the task, job or job manager objects may be stored in the database 669 .
  • the database 669 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.
  • the database 669 can be an in process database 669 of the job manager 265 or it can be a remote database 669 available on another computing device 102 ′ or another server 260 ′. Furthermore, each instance of the job manager 265 A- 265 N could use a different database and operating system than other instances of the job manager 265 A- 265 N, or be using a local database while another job manager 265 A- 265 N uses a remote database on another server 160 ′.
  • One ordinarily skilled in the art will appreciate the various deployments of local or remote database access for each of the one or more job managers 265 A- 265 N.
  • the job manager 265 can be configured to execute certain functions based on changes of the state of a job in the queue 267 .
  • the technical computing client 250 can setup functions to be called when a job is created in a job queue 267 , when the job is queued, when a job is running or when a job is finished.
  • the job manager 265 is to call these functions when the appropriate change in the state of job occurs.
  • 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.
  • the technical computing client 250 submits a job, Job 1 , comprised of one or more tasks, such as Task 1 and Task 2 , to the job manager 265 .
  • the job manager receives the job, e.g., job 1 , and places the job into a job queue 267 .
  • the job runner 667 then obtains the one or more tasks from the first job submitted to the job queue 267 .
  • a technical computing worker 270 registers with the job manager 265 and is listed in the worker pool 668 of the job manager 265 . From the worker pool 668 , the job runner 667 determines a technical computing worker 270 A- 270 N to submit the task for processing.
  • the technical computing worker 270 A- 270 N 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 the technical computing worker 270 updates the task object to provide a result of the task.
  • 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®.
  • the task object may contain an error field to which the technical computing worker 270 A- 270 N updated to indicate any error conditions in performing the task or executing the function of the task.
  • the job manager 265 checks to see if this is the last result to be obtained from a technical computing worker 270 A- 270 N for the job currently being processed. If the result is the last result, the job manager 265 can provide the set of task results for the completed job to the technical computing client 250 .
  • 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.
  • the software components of the MATLAB®-based distributed computing application can be implemented as services which can be discovered and looked-up via advertising.
  • FIG. 7 an exemplary embodiment of the invention is shown implementing a service oriented approach with Jini network technology.
  • the technical computing client 250 the technical computing workers 270 A- 270 N, job managers 265 A- 265 N, automatic task distribution mechanisms 260 A- 260 N are in communication over the network 140 via network communication channels 130 .
  • a network server 760 in communication with the network 140 through the network communication channel 130 .
  • the network server 760 hosts a code base server 710 .
  • the code base server 710 is an ftp server.
  • the code base server 710 is a web server, such as Java web server, or an http server.
  • the code base server 710 is capable of and configured to upload files, including class or interface files.
  • the code base server 710 may upload JAR files.
  • the code base server 710 may be available on the network 140 to Jini based services to obtain class files as a service on the network 140 may need, or it may be available to a technical computing client 250 to determine the interface to a service on the network 140 .
  • Jini services are available on the network server 760 on the network 140 : Reggie 718 , Mahalo 716 , Fiddler 714 and Norm 712 . These services are part of the Sun Technology Jini network technology implementation.
  • Reggie 718 is a Jini service that provides service registration and discovery. This allows clients of a service to find the service on the network 140 without knowing the name of the computing device the service is running on.
  • Mahalo 716 is a transaction manager service that provides fault tolerant transactions between services and clients of the service accessing the service.
  • Fiddler 714 is a lookup discovery service.
  • a Jini based service needs to register itself with an instance of Reggie in order to be discoverable on the network 140 .
  • the lookup discovery service of Fiddler 714 allows the service to find new Reggie services and register with them while inactive.
  • Norm 712 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 any computing device 102 on the network 140 capable of running these services and can be run on a single java virtual machine (JVM).
  • JVM java virtual machine
  • the technical computing workers 270 A- 270 N which provide MATLAB® sessions, are made available as Jini Services to support the direct task distribution mode of operation of the invention.
  • the technical computing workers 270 A- 270 N register with a lookup service such as Reggie 718 . This allows the technical computing workers 270 A- 270 N to be discoverable on the network 140 by a technical computing client 250 without the technical computing client 250 knowing information like the host name of the workstations 170 A- 170 N the technical computing workers 270 A- 270 N are running on, or the port number to which a specific technical computing worker 270 A- 270 N service is listening on, or a worker name associated with a technical computing worker 270 A- 270 N.
  • the technical computing workers 270 A- 270 N also support service activation with an activation daemon 740 A- 740 N software component. Activation allows a technical computing worker service 270 A- 270 N to register with an activation daemon 740 A- 740 B to exit and become inactive, but still be available to a technical computing client 250 .
  • the MATLAB®-based technical computing workers 270 A- 270 N can be activated by an activation daemon 740 A- 740 N. This means that an activation daemon 740 A- 740 N starts and stops the technical computing worker 270 A- 270 N.
  • the technical computing worker 270 A service registers with the activation daemon 740 A on workstation 170 A.
  • the technical computing worker 270 A includes the activation states of active, inactive and destroyed.
  • the technical computing worker 270 A is started and is available for remote method calls from a technical computing client 250 .
  • 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.
  • the technical computing client 250 is not started, but is still available for remote method calls from a technical computing client 250 .
  • the technical computing worker service 270 A will be started by the activation daemon 740 A, and the method call will be executed by the technical computing worker service 270 A.
  • the technical computing worker service 270 A is not running and is not registered with the activation daemon 740 A.
  • the technical computing worker service 270 A is not available for remote calls from a technical computing client 270 .
  • the activation daemons 740 A- 740 N provide persistence and maintain the state of the technical computing worker services 270 A- 270 N.
  • the activation feature of technical computing worker services 270 A- 270 N saves computing resources on workstations hosting the technical computing worker, and also increases service reliability. For example, if the technical computing worker service 270 A terminates abruptly, the activation daemon 740 A will automatically restart the next time a call is made to it.
  • the activation daemon 740 A- 740 N also provides for the graceful termination of the technical computing worker service 270 A- 270 N. If an inactivate command is sent to a technical computing worker service 270 A- 270 N, the technical computing worker service 270 A- 270 N can complete the processing of outstanding method calls before terminating. Alternatively, a command can be sent to the technical computing worker 270 A- 270 N to force immediate termination in the middle of processing a task.
  • a technical computing worker 270 A can be configured and controlled to shutdown after the completion of processing of a task. If the technical computing worker 270 A 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.
  • the technical computing worker services 270 A- 270 N can default to a non-debug mode when the technical computing worker service 270 A- 270 N is started, either by the activation daemon 740 A- 740 N or by other conventional means.
  • the activation daemon 740 A- 740 N and/or the technical computing worker service 270 A- 270 N can be configured to start in debug mode, giving access to command line interface of the technical computing worker 270 A- 270 N.
  • the job managers 265 A- 265 N and automatic task distribution mechanisms 260 A- 260 N as depicted in FIG. 7 can also be implemented as services.
  • the job managers 265 A- 265 N and automatic task distribution mechanisms 260 A- 260 N can support lookup registration and discovery so that a technical computing client 250 A can find the service without knowing the associated name of the service, the host name of the server 160 running the service, or the port name the service is listening on.
  • the job manager 265 A- 265 N and automatic task distribution mechanism services 260 A- 260 N can be supported by activation daemons as with the technical computing worker services 270 A- 270 N.
  • the services of the technical computing worker 270 A- 270 N, job manager 265 A- 265 N and the automatic task distribution mechanism 260 A- 260 N 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.
  • the technical computing workers 270 A- 270 N may each include a technical computing worker administration software component 740 A- 740 B
  • the job managers 265 A- 265 N may each include a job manager administration software component 730 A- 730 B
  • the automatic task distribution mechanisms 260 A- 260 N may also each include an administration software component 760 A- 760 N.
  • 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 the technical computing client 250 , and may be configured to only be available to system administrators or to those users with certain access rights to such functionality.
  • the administration component 760 A of the automatic task distribution mechanism 260 A 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 repository 664 , or space, as described in the user defined data classes below.
  • the job manager administration component 730 A may provide a graphical view of all the jobs in the job queue 267 of the job manager 265 . 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 the queue 267 . 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 manager 266 as described in the user defined data classes below.
  • a graphical user interface to the technical computing worker administration component 750 A- 750 N may provide a user the ability to change the activation state, stop and start, or debug the technical computing worker service 270 A- 270 N. 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 technical computer worker 270 A- 270 N as described in the user defined data classes below.
  • FIG. 8A depicts one embodiment of using user defined data classes as part of the MATLAB® programming language.
  • the system 800 makes use of task objects 810 , result objects 812 , job objects 814 and jobresults objects 816 These objects present a lower level user interaction mechanism to interact with the task distribution functionality of the system 800 .
  • the technical computing client 250 creates or declares a task object 810 .
  • the task object 810 is a user defined data class containing a MATLAB® command, input data and number of arguments.
  • the technical computing client 250 submits the task object, in the automated mode of operation, to the automatic task distribution mechanism 260 , which stores the task object 810 in the object exchange repository 662 .
  • a technical computing worker 270 listening and waiting for a task object 810 to appear in the object exchange repository 662 takes the task object 810 to perform technical computing of the task.
  • the technical computing worker 270 obtains the MATLAB® command and arguments from the properties of the task object 810 and performs technical computing on the task in accordance with the command.
  • the technical computing worker 270 then creates or specifies a result object 812 , which is a user defined data object containing the output data resulting from the execution of a task represented by a task object 810 .
  • the technical computing worker 270 then writes the result object 812 to the object exchange repository 662 .
  • the technical computing client 250 listens and waits for the appearance of the result object 812 in the object exchange repository 662 . After the result object 812 appears in the object exchange repository, the technical computing client 250 takes the result object 812 from the object exchange repository and retrieves result information from the properties of the result object 812 .
  • the technical computing client 250 creates or declares a job object 814 , which is a user defined data object containing an array of task objects 810 .
  • the technical computing client 250 then submits the job object 814 to the job manager 265 for processing.
  • the job manager 265 then submits the one or more task objects 820 defined in the job object 814 to the object exchange repository 662 for processing by a technical computing worker 270 .
  • the technical computing worker 270 listening for the appearance of the task objects 820 , takes the task objects 820 and performs technical computing on the function as defined by each task object.
  • the technical computing worker 270 then generates results and creates or specifies the result objects 822 representing the output generated for each function of each of the task objects 820 of the job object 814 .
  • the technical computing worker 270 then writes the result objects 822 to the object exchange repository 662 .
  • the job manager 662 listening for the appearance of the result objects 822 takes the result objects from the object exchange repository 662 .
  • the job manager 265 then creates or specifies the jobresults object 816 , which in an object that provides an array of result objects 844 for each task object defined in a job object 814 .
  • the job manager then provides the jobresults object 816 to the technical computing client 250 .
  • 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 in FIG. 4 .
  • TaskID unique task identifier JobID non-null if this task is part of a job
  • evaluateTask evaluate the function defined by instance of Task class getResult get instance of Result class generated by evaluatetask
  • 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
  • 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
  • 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
  • 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 of technical computing workers 270 A- 270 N, automatic task distribution mechanisms 260 A- 260 N, or spaces, and job managers 265 A- 265 N as depicted in FIG. 7 . With these methods, a technical computing client 250 does not need to have previous knowledge of any technical computing worker 270 A- 270 N, any of the automatic task distribution mechanisms 260 A- 260 N or any job managers 265 A- 265 N. The technical computing client 250 can use these methods to discover the name and number of such services available on the network 140 .
  • the programming language of MATLAB® may support the three modes of operation as described with FIGS. 3A-3C .
  • the following program instructions show a programming usage of the above described user defined data classes for each of these modes of operation:
  • 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.
  • 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.
  • 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.
  • 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.
  • the technical computing client 250 creates or declares a job object 860 residing in the job manager 265 .
  • the job object comprises one or more task objects 870 A- 870 N.
  • the job object 860 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 object 870 A- 870 N is an object that defines a function to be executed by a technical computing worker 270 .
  • the function contains a MATLAB® command, input data and number of arguments.
  • the task object 870 A- 870 N defines additional task properties, such as those defined below.
  • the task object 870 A- 870 N may have a state property to indicate the current state of the task.
  • the technical computing client 250 may interface with the job manager 265 through a job manager object 865 residing on the job manager 265 .
  • the job manager object 865 may have properties to define configuration and other details about the job manager 265 as described below.
  • the job manager object 865 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.
  • 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 the job manager 265 .
  • the technical computing client 250 submits the job to the job manager 265 via the job object 865 .
  • the job manager 265 obtains each of the task objects 870 A- 870 N from the job object 865 .
  • the job manager puts the job of the job object 860 into the job queue 267 .
  • the job runner 667 obtains the one or more task objects 870 A- 870 N from the job object 860 .
  • the job runner 667 with the worker pool 668 determines a technical computing worker 270 to process a task.
  • the job runner 667 then submits a task, via a task object 870 A- 870 N to an assigned technical computing worker 270 .
  • the technical computing worker 270 obtains the function to execute from the properties of the task object 870 A- 870 N and performs technical computing of the task in accordance with the function. The technical computing worker 270 then obtains the results of the function and updates one or more properties of the task object 870 A- 870 N with information about the results. In the case of any errors, the technical computing worker 270 may update any error properties of the task object 870 A- 870 N. In a similar manner as the technical computing client 250 , the technical computing worker 270 may use proxy or facade objects to interface with the job 860 , job manager 865 or task 870 A- 870 N objects residing in the job manager 265 .
  • the job manager 265 then updates the job object 860 with updated task objects 870 A- 870 N containing the results of each task.
  • the job manager 265 may also update other properties of the job object 860 , such as start and finish times of the job, to reflect other information or status of the job.
  • the job manager 265 then provides the updated job object 860 to the technical computing client 250 .
  • the technical computing client 250 then can retrieve the results of each task from the updated job object 860 .
  • 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 in FIG. 4 .
  • 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.
  • 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(. . .
  • 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.
  • 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);
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the structure field names are object property names and the field values are the requested property values.
  • a property value 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.
  • 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.
  • 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.
  • 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.
  • 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
  • Name Indicate the name of the job manager State Indicate the current state of the job manager
  • 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.
  • 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.
  • the distributed system 910 supports the delegation of tasks from a technical computing client 250 to remote technical computing workers 270 A- 270 N leveraging the processing capability of each of the workstations 170 A- 170 N hosting each of the technical computing workers 270 A- 270 N.
  • the tasks are executed independently of each other and do not require the technical computing workers 270 A- 270 B to communicate with each other.
  • the streaming, or serial, processing system 910 allows serial processing to occur via multiple technical computing workers 270 A- 270 N on multiple workstations 170 A- 170 N.
  • a technical computing client 250 A submits a job requiring a task to be processed serially from technical computing worker 270 A to technical computing worker 270 B then to technical computing worker 270 N.
  • technical computing worker 270 A completes its technical computing of the task
  • technical computing worker 270 A submits the task to technical computing worker 270 B for further processing.
  • the task can be submitted to additional technical computing workers 270 N for further processing until the task is complete in accordance with its task definition.
  • the last technical computing worker 270 N to perform technical computing on the task submits the result to the technical computing client 250 .
  • the streaming processing system 920 can take advantage of specific workstations 170 A- 170 N that may have faster processors for performing processor intensive portions of technical computing of the task or take advantage of technical computing workers 270 A- 270 N with access to specific data sets or external control instrumentation as required for computation of the task.
  • a parallel system 930 is depicted which combines the distributed and streaming configuration of the systems ( 900 and 910 ) in FIG. 9A .
  • technical computing workers 270 A and 270 B and 270 N 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.
  • technical computing worker 270 A can submit a task for further processing to technical computing worker 270 B, and in turn, technical computing worker 270 B can submit the task for further processing by technical computing worker 270 N.
  • the technical computing worker 270 N when it completes processing may return a result back to the automatic task distribution mechanism 260 or the technical computing client 250 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 distributed system 1000 in the distributed computing environment.
  • the instrument-based distributed computing system 1000 may include one or more clients 150 , servers 160 , workstations 170 and instruments 180 coupled to a network 140 .
  • the client 150 , server 160 and workstation may run the technical computing client 250 , the automatic distribution mechanism 260 and the technical computing worker, respectively, as described above with reference to FIGS. 1A-9B .
  • the instrument 180 may run the technical computing client 250 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 to FIGS. 12A-12C .
  • instrument-based distributed system 1000 is illustrative and may not include all of the client 150 , server 160 , workstation 170 and instrument 180 .
  • the instrument-based distributed system 1000 can be implemented with a various combinations of the client 150 , server 160 , workstation 170 and instrument 180 in other embodiments.
  • the client 150 , server 160 , workstation 170 and instrument 180 are coupled to the network 140 .
  • the client 150 or instrument 180 may communicate directly with the workstation 170 or other instruments 180 as described above with reference to FIG. 3A .
  • the client 150 or instrument 180 may communicate with the workstation 170 or other instruments 180 via the server 160 , which runs the automatic task distribution mechanism 260 , as described above with reference to FIGS. 3B-4 .
  • the workstations 170 or instruments 180 may or may not communicate with each other depending on the communication topology of the distributed computing system 1000 , as described above with reference to FIGS. 9A and 9B .
  • FIG. 11 is a block diagram showing an exemplary instrument utilized in the illustrative embodiment of the present invention.
  • the instrument 180 may include instrumentation functionalities 1110 , a technical computing client 250 , a technical computing worker 270 , an operating system 1120 and a network interface 118 .
  • the instrumentation functionalities 1110 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.
  • the instrument 180 refers to any tool that includes one or more instrumentation functionalities.
  • the technical computing client 250 and the technical computing worker 270 installed on the instrument 180 may include the MATLAB®-based distributed computing application 120 as described above with reference to FIGS. 2A-2C .
  • the technical computing client 250 creates a job including one or more tasks.
  • the technical computing client 250 distributes the job to the technical computing workers for the distributed execution of the job.
  • the technical computing worker 270 performs technical computing tasks defined by the client 250 .
  • the instrument 180 may include the technical computing client 250 and/or the technical computing worker 270 . If the instrument 180 is installed with the technical computing client 250 , the instrument 110 may operate to generate a job and distribute the job to workstations 170 and/or other instruments 180 , as the client 150 does. If the instrument 180 is installed with the technical computing worker 270 , the instrument 110 may operate to receive and execute the tasks, as the workstations 170 do.
  • the instrument 180 may include an operating system 1130 that enables users to install their own applications, such as the technical computing client 250 and the technical computing worker 270 .
  • the operating system 1130 enables the applications to run on the instrument 180 .
  • the instrument 180 may have, for example, a standard Windows® operating system so that the users can install their own applications on the instrument 180 .
  • the Windows operating system is an exemplary operating system that can be included in the instrument 180 and the operating system 1130 may include any other operating systems described above with reference to FIG. 1A .
  • the instrument 180 may communicate with the client 150 , server 160 , workstation 170 or other instruments 180 via the network interface 118 .
  • the network interface 1130 may include any network interfaces described above with reference to FIG. 1A .
  • the network interface 118 may include a bus interface, such as a general purpose interface bus (GPIB) interface.
  • the network interface 1140 may also include any other bus interfaces, such as Universal Serial Bus (USB), Myrinet, Peripheral Component Interconnect (PCI), PCI extended (PCI-X), etc.
  • USB Universal Serial Bus
  • PCI Peripheral Component Interconnect
  • PCI-X PCI extended
  • the network interface 1140 may include an LXI (LAN extension for instrumentation) interface, which is based on industry standard Ethernet technology.
  • the instrument 180 running the workers may have the capability of accelerating the execution of tasks.
  • 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.
  • the instrument 180 may have multiple processors or CPUs to run the workers.
  • the instrument 180 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.
  • 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 the client 150 , workstations 170 and instruments 180 coupled to the network 140 .
  • the technical computing client 250 runs on the client 150 .
  • the technical computing the technical computing workers 270 may run on the workstations 170 and instruments 180 .
  • the technical computing client 250 creates a job and distributes the job to the technical computing workers 270 on the workstations 170 and instruments 180 .
  • the technical computing workers 270 on the workstations 170 and instruments 180 execute the job and return the execution results to the technical computing client 250 on the client 150 .
  • the system may include a server for the automatic distribution of the tasks, as described above with reference to FIG. 10 .
  • FIG. 12B is a block diagram showing another exemplary instrument-based distributed computing system.
  • the instrument-based distributed computing system may include workstations 170 and instruments 180 coupled to the network 140 .
  • the technical computing client 250 runs on the instrument 180 .
  • the technical computing workers 270 run on the workstations 170 and other instruments 180 .
  • the technical computing client 250 creates a job and distributes the job to the technical computing workers 270 on the workstations 150 and instruments 180 .
  • the technical computing workers 270 on the workstations 170 and instruments 180 execute the job and return the execution results to the technical computing client on the client 150 .
  • the system may include a server for the automatic distribution of the tasks, as described above with reference to FIG. 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 the client 150 , workstation 170 and instrument 180 coupled to the network 140 .
  • the system may also include a sub-cluster 190 coupled to the network 140 .
  • the sub-cluster 190 may include clients, servers, workstations and instruments.
  • the sub-cluster 190 may run additional technical computing clients and technical computing workers to distribute and execute the job defined by the technical computing client 250 on the client 150 or instrument 180 .
  • the technical computing client 250 may create a job and distribute the job to the sub-cluster 190 .
  • the technical computing workers in the sub-cluster 190 execute the job and return the execution results to the technical computing client 250 on the client 150 or instrument 180 .
  • the sub-cluster 190 may include a distribution mechanism for distributing the job to the workstations and instruments in the sub-cluster 190 .
  • 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 the technical computing client 250 and the technical computing worker 270 , 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.
  • 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 a test environment 1200 provided in the illustrative embodiment of the present invention.
  • various types of resources 1210 may be used for providing units under test 1230 .
  • the resources 1210 may include software tools and hardware tools.
  • the test environment 1200 may include a test manager 1220 .
  • users may input control data 1240 for setting conditions for testing the units under test 1230 in the test environment 1200 .
  • the control data 1240 may include a sequence of test steps that specifies the ordering of the resources to be used by the test manager 1220 .
  • the users may also input the variables and parameters of the test that can be used as arguments to call the functions provided by the resources 1210 .
  • the units under test 1230 may include one or more pieces of hardware, software and/or programs, such as models and/or code.
  • the test manager 1220 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 under test 1230 .
  • 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.
  • 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 the test manager 120 .
  • 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.
  • the client 150 defines a test for testing units under test (step 1302 ).
  • the test may be defined to include one or more test steps. Each test step may test different units under test.
  • the client 150 then submits at least a portion of the test (step 1304 ) to an instrument 180 or workstation 170 that contains the technical computing worker 270 .
  • the client 150 then submits each test step to different workstations 170 and/or instruments 180 .
  • the technical computing worker 270 receives at least a portion of the test (step 1306 ) and performs the requested technical computing as defined by the test (step 1308 ).
  • an associated result may be generated (step 1310 ). In alternative embodiments, either no result is generated, or no result is required to be returned to the client 150 .
  • the workstations 170 and/or instruments 180 provide the result (step 1312 ) to the client 150 , and the client 150 obtains the result from the workstations 170 and/or instruments 180 (step 1314 ).
  • the distributing operation is illustrative and the test may be distributed by the operations described above with reference to FIGS. 5B-5D .
  • the distribution of the test may be performed in the same way as described above with reference to FIGS. 6A-9B .
  • the instrument 180 may be used as a technical computing client and/or worker and as an instrumentation tool.
  • the instrument 180 may be used as an instrumentation tool performing part of the test that acts on the information collected by the instrument 180 .
  • the instrument 180 may be used as a pure technical computing client or worker utilizing the technical computing functionality of the instrument 180 .
  • the instrument 180 may be used as both a technical computing client/worker and an instrumentation tool.
  • the instrument 180 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.
  • the technical computing functionality and the instrumentation functionality of the instrument 180 may need to be compromised depending on the capability of the instrument 180 to support for both of the functionalities concurrently.
  • One exemplary way to compromise these functionalities is to pause/stop the technical computing functionality when the instrument 180 is needed to make a measurement. When the measurement is completed, the instrument 180 can continue to perform the technical computing functionality.
  • the technical computing capability of the instrument 180 can allow users to utilize the additional computational power in the instrument 180 to perform a fast result calculation of a test in the test environment.
  • 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.
  • 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.
  • a portion of the distributed array may be processed separately and independently. For example, take the following iterators:
  • 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 which workers 270 are not currently executing a program or which workers 270 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.
  • the decomposition of the iterator can be based on one or more operational characteristics of the worker, or of the computing device 102 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.
  • Different random submatrices, or arrays are generated on each one of the sixteen (16) workers.
  • 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.
  • 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.
  • the distributed array can be distributed by rows or a portion of rows and columns.
  • 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.
  • 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.
  • a first worker may be assigned column 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 on column 1 of the array, i.e., read and write access.
  • 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 on column 1, it no longer will have read access to columns 2 and 3 of the distributed array.
  • 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:
  • 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.
  • the present invention relates to methods for programmatically providing for distributed array processing as depicted in FIG. 15 .
  • method 1500 depicts the processing of a distributed array in execution in multiple workers.
  • a worker is executing a program flow of a program (job or test) invoked for execution.
  • the worker 270 at step 1504 interprets a distributed array construct in a program statement, such as a program statement comprising the keyword darray.
  • the worker 270 evaluates the distributed array construct to determine the portion of the distributed array to store locally.
  • the distributed array may be decomposed in a variety of ways.
  • the worker 270 may store a specific column of the array to perform local processing. After determining and storing the portion of the distributed array, the worker 270 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, the worker 270 may access or obtain data values of other portions of the array that have been cached.
  • method 1500 is discussed with regards to one worker, the same flow diagram will apply to multiple workers 270 running the same program so that at steps 1504 , 1506 and 1508 the worker interpreting the distributed array determines what portion of the array to store and process locally.

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 of FIG. 3A;
  • FIG. 5B is a flow diagram of steps performed in an embodiment of FIG. 3B;
  • FIG. 5C and FIG. 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 in FIG. 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 in FIG. 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 a computing device 102 having memory 106, on which software according to one embodiment of the present invention may be stored, a processor (CPU) 104 for executing software stored in the memory 106, and other programs for controlling system hardware. The memory 106 may comprise a computer system memory or random access memory such as DRAM, SRAM, EDO RAM, etc. The memory 106 may comprise other types of memory as well, or combinations thereof. A human user may interact with the computing device 102 through a visual display device 114 such as a computer monitor, which may include a graphical user interface (GUI). The computing device 102 may include other I/O devices such a keyboard 110 and a pointing device 112, for example a mouse, for receiving input from a user. Optionally, the keyboard 110 and the pointing device 112 may be connected to the visual display device 114. The computing device 102 may include other suitable conventional I/O peripherals. The computing device 102 may support any suitable installation medium 116, 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 distributed computing application 120. The computing device 102 may further comprise a storage device 108, 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 distributed computing application 120 of an embodiment of the present invention. Additionally, the operating system and the MATLAB®-based distributed computing application 120 of the present invention can be run from a bootable CD, such as, for example, KNOPPIX®, a bootable CD for GNU/Linux.
  • Additionally, the computing device 102 may include a network interface 118 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. The network interface 118 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 the computing device 118 to any type of network capable of communication and performing the operations described herein. Moreover, the computing device 102 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 distributed computing application 120 of an embodiment of the present invention running in a stand-alone system configuration of a single computing device 102. FIG. 1B depicts another environment suitable for practicing an illustrative embodiment of the present invention, where functionality of the MATLAB®-based distributed computing application 120 is distributed across multiple computing devices (102′, 102″ and 102′″). In a broad overview, the system 100 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. The system 100 includes a client 150 (e.g., a first computing device 102′) in communications through a network communication channel 130 with a server computer 160, also known as a server, (e.g., a second computing device 102″) over a network 140 and the server in communications through a network communications channel 130 with a workstation (e.g., a third computing device 102′″) over the network 140′. The client 150, the server 160, and the workstation 170 can be connected 130 to the networks 140 and/or 140′ 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 the client 150, server 160 and workstation 170 can be any type of computing device (102′, 102″ and 102′″) as described above and respectively configured to be capable of computing and communicating the operations described herein.
  • In one embodiment, each of the client 150, server 160 and workstation 170 are configured to and capable of running at least a portion of the present invention of the MATLAB®-based distributed computing application 120. As a distributed software application, the MATLAB®-based distributed computing application has one or more software components that run on each of the client 150, server 160 and workstation 170, respectively, and work in communication and in collaboration with each other to meet the functionality of the overall application. For example, the client 150 may hold a graphical modeling environment that is capable of specifying block diagram models and technical computing tasks to analyze the model. The client 150 may have software components configured to and capable of submitting the tasks to the server 160. The server 160 may have software components configured to and capable of receiving the tasks submitted by the client 150 and for determining a workstation 170 to assign the task for technical computing. The workstation 170 may hold software components capable of providing a technical computing environment to perform technical computing of the tasks assigned from the server 160 and submitted by the client 150. In summary, the technical computing environment and software components of the MATLAB®-based distributed computing application 120 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 distributed computing application 120. In brief overview, the system 200 of the MATLAB®-based distributed computing application 120 is a two-node distributed system comprising a technical computing client application 250, or technical computing client, running on a client 150 computer and a technical computing worker application 270, or technical computing worker, running on a workstation 170. The technical computing client 250 is in communications with the technical computing worker 270 through a network communications channel 130 over a network 140.
  • The technical computing client 250 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. The technical computing client 250 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, the technical computing client 250 can be any of the software programs available in the MATLAB® product family. Furthermore, the technical computing client 250 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 the technical computing client 250, functions can be defined representing a technical computing task to be executed by either a technical computing environment local to the client computer 150, or remote on the workstation 270. The local technical computing environment may be part of the technical computing client 250, or a technical computing worker running on the client computer 150. 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 the technical computing worker 270 on the workstation 170, or alternatively, on the client 150. For example, the technical computing client 250 may declare a function to generate a random set of ten numbers and further delegate that the technical computing worker 270 running on the workstation 170 execute the function. Also, the application programming interface and programming language of the MATLAB®-based client 250 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, the technical computing client 250 may declare a variable to hold a result returned from the technical computing worker 270 performing technical computing of the random generation function.
  • The distributed functionality features of the programming languages of the MATLAB®-based client 250 allows the technical computing client 250 to use the computing resources that may be available from a technical computing worker 270 on the workstation 170 to perform technical computing of the task. This frees up the technical computing client 250 to perform other tasks, or the client computer 150 to execute other software applications.
  • The technical computing worker 270 of the system 200 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 the technical computing client 250. The technical computing worker 270 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 running technical computing worker 270 by which a technical computing client can connect and access its functionality. The technical computing worker 270 can include all the functionality and software components of the technical computing client 250, or it can just include those software components it may need to perform technical computing of tasks it receives for execution. The technical computing worker 270 may be configured to and capable of running any of the modules, libraries or software components of the MATLAB® product family. As such, the technical computing worker 270 may have all or a portion of the software components of MATLAB® installed on the workstation 170, or alternatively, accessible on another system in the network 140. The technical computing worker 270 has mechanisms, described in detail later, to receive a task distributed from the technical computing client 250. The technical computing worker 270 is capable of performing technical computing of the task as if the technical computing client 250 was performing the technical computing in its own technical computing environment. The technical computing worker 270 also has mechanisms, to return a result generated by the technical computing of the task to the technical computing client 250.
  • The technical computing worker 270 can be available on an as needed basis to the technical computing client 250. When not performing technical computing of tasks from the technical computing client 250, the workstation 170 of the technical computing worker 270 can be executing other software programs, or the technical computing worker 270 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 in FIG. 2B. The multi-tier distributed system 205 includes a technical computing client 250 running on a client computer 150 in communications over a network communication channel 130 to a server 160 on a network 140. The server 160 comprises an automatic task distribution mechanism 260 and a job manager 265. The job manager 265 interfaces with the automatic task distribution mechanism 260 on the server 160. The automatic task distribution mechanism 260 communicates over a network communication channel 130 on the network 140 to the technical computing worker 270 on the workstation 170.
  • The automatic task distribution mechanism 260 comprises one or more application software components to provide for the automatic distribution of tasks from the technical computing client 250 to the technical computing worker 270. The automatic task distribution mechanism 260 allows the technical computing client 250 to delegate the management of task distribution to the automatic task distribution mechanism 260. For example, with the programming language of MATLAB®, a task can be defined and submitted to the automatic task distribution mechanism 260 without specifying which technical computing worker 270 is to perform the technical computing of the task. The technical computing client 250 does not need to know the specifics of the technical computing worker 270. The technical computing client can define a function to submit the task to the automatic task distribution mechanism 260, and get a result of the task from the automatic task distribution mechanism 260. As such, the automatic task distribution mechanism provides a level of indirection between the technical computing client 250 and the technical computing worker 270.
  • This eases the distributed programming and integration burden on the technical computing client 250. The technical computing client 250 does not need to have prior knowledge of the availability of the technical computing worker 270. For multiple task submissions from the technical computing client 250, the automatic task distribution mechanism 260 can manage and handle the delegations of the tasks to the same technical computing worker 270, or to other technical computing workers and hold the results of the tasks on behalf of the technical computing client 250 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, a job manager module 265, or “job manager”, is included as an interface to the task and result management functionality of the automatic task distribution mechanism 260. The job manager 265 can comprise an object-oriented interface to provide control of delegating tasks and obtaining results in the multi-tiered distributed system 205. The job manager 265 provides a level of programming and integration abstraction above the details of inter-process communications and workflow between the automatic task distribution mechanism 260 and the technical computing worker 270. The job manager 265 also provides an interface for managing a group of tasks collectively as a single unit called a job, and on behalf of a technical computing client 250, submitting those tasks making up the job, and obtaining the results of each of the tasks until the job is completed. Alternatively, the automatic task distribution mechanism 260 can include the functionality and object-oriented interface of the job manager 265, or the automatic task distribution mechanism 260 and the job manager 265 can be combined into a single application, or software component. In an exemplary embodiment, the job manager 265 comprises both the functionality of the job manager 265 and the automatic task distribution mechanism 260. One ordinarily skilled in the art will recognize the functions and operations of the job manager 265 and the automatic task distribution mechanism 260 can be combined in various software components, applications and interfaces.
  • Referring now to FIG. 2C, an exemplary embodiment of the present invention is shown with multiple technical computing workers 270A-270N hosted on a plurality of workstations 170A-170N. The technical computing client 250 may be in communication through the network communication channel 130 on the network 140 with one, some or all of the technical computing workers 270A-270N. In a similar manner, the automatic task distribution mechanism 260 may be in communication through the network communication channel 130 on the network 140 with one, some or all of the technical computing workers 270A-270N. As such, the technical computing client 250 and/or the automatic task distribution mechanism 260 can distribute tasks to multiple technical computing workers 270A-270N to scale the distributed system and increase computation time of tasks. As also shown in FIG. 2C, the technical computing workers 270A-270B can be hosted on the same workstation 170A, or a single technical computing worker 270C can have a dedicated workstation 170B. Alternatively, one or more of the technical computing workers 270A-270N can be hosted on either the client 150 or the server 160.
  • The computing devices (102, 102′, 102″, 102′″) depicted in FIGS. 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 the client 150, the server 160 and the workstation 170 can be running the same or different operating systems. For example, the client 150 can running Microsoft® Windows, the server 160 can be running a version of Unix, and the workstation a version of Linux. Or each of the client 150, the server 160 and the workstation 170 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 one computing device 102 and a 64 bit processor of another computing device 102′. In a distributed system, such as the system depicted in FIG. 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″, and 102′″).
  • 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 a client 150, server 160 and workstation 170, any other system and/or deployment architecture that combines and/or distributes one or more of the technical computing client 250, job manager 265, automatic task distribution mechanism 260 and technical computing worker 270 across any other computing devices and operating systems available in the network 140 may be used. Alternatively, all the software components of the MATLAB®-based distributed computing application can run on a single computing device 102, such as the client 150, server 160 or the workstation 170.
  • 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. In FIGS. 3A, 3B and 3C, 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 and FIG. 3C, a batch mode of automated distribution. Additionally, FIG. 3D depicts an exemplary embodiment of the batch mode of automated distribution.
  • The direct distribution system 305 of FIG. 3A is intended for those users who desire a high level of control over which technical computing worker 270A-270N executes a particular task. In brief overview of the direct distribution system 305, the technical computing client 250 is in communications with a plurality of technical computing workers, 270A-270N, each running on their own workstation 170A-170N. In an alternative embodiment, one or more of these technical computing workers 270A-270N can be running on the same computing device, e.g., workstation 270A, or on the client 150 or the server 160. This direct distribution system 305 allows a task to be sent to a particular technical computing worker, e.g., technical computing worker 270A of a plurality of technical computing workers 270A-270N. Then, the technical computing client 250 can continue with other work while the specified technical computing worker, e.g., technical computing worker 270A, is performing technical computing of the submitted task. Some time after submitting the task to the technical computing worker 270A, the technical computing client 250 can then obtain the result of the task from the technical computing worker 270A. Furthermore, each technical computing worker 270N can process multiple tasks, e.g., TaskN-M, and for each task produce a result, e.g., ResultN-M. Alternatively, the technical computing worker 270A 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 known workstations 170A-170N and technical computing workers 270A-270N. A task can be delegated to a specified technical computing worker running 270A on a workstation 170A that has a higher speed configuration than the other workstations 170B-170N. For example, a longer task could be executed on such a workstation 170A in order to speed the overall computation time.
  • As further depicted in FIG. 3A, the technical computing client 250 of the direct distribution system 305 can submit multiple tasks (e.g., TaskN-M) to each of the multiple technical computing workers 270A-270N. For example, the technical computing client 250 submits task 1 to technical computing worker 270A, submits task 2 to technical computing worker 270B, and submits task N to technical computing worker 270N. The technical computing client 250 can submit task1, task2 and taskN-M one immediately after another or within a certain time between each other. As such, the technical computing workers 270A-270N can be performing technical computing of their respective tasks independently and in parallel to each other. Alternatively, the technical computing workers 270A-270N may perform technical computing of their respective task while the other technical computing workers are idle.
  • In another embodiment, the technical computing workers 270A-270N may include interfaces and communication channels to interact with each other as depicted by the phantom arrowed lines between the technical computing workers 270A-270N in FIG. 3A. In such an embodiment, technical computing worker 270A 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 by technical computing worker 270B. Also, the technical computing worker 270A may also submit the result of its technical computing of task1 to the technical computing client 250, before or after, submitting the task to technical computing worker 270B for further processing. Technical computing worker 270B may in turn perform technical computing of task1, and subsequently submit task1 for further processing by technical computing worker 270N. For additional configurability, the technical computing workers 270A-270N can obtain information with the task about the identification of other technical computing workers 270A-270N in the system. This information would be used to communicate and interact with another technical computing worker. Alternatively, a technical computing worker 270A may find another technical computing worker 270B-270N by making a function or system call, or a method call to a service provider on the network 140. In such a configuration, technical computing workers 270A-270N can either execute tasks independently and in parallel to each other, or also execute tasks serially and subsequent to each other.
  • Referring now to FIG. 3B, the automated task distribution mode embodied in system 310 is intended to provide a configuration where the user does not want to control which technical computing worker 270A-270N executes a particular task. In brief overview of the automated distribution mode of system 310, a technical computing client 250 is in communication with the automatic task distribution mechanism 260 running on the server 160. The automatic task distribution mechanism 260 is in communications with a plurality of technical computing workers 270A-270N. Under this mode of operation, the technical computing client 250 is not required to have any specific knowledge of the technical computing workers 270A-270N, e.g., the name of the workstation running a technical computing worker 270A-270N, or the availability of the technical computing worker 270A-270N to perform technical computing of a task. In alternative embodiments, it may have prior knowledge of all or a portion of the technical computing workers 270A-270N available on the network. Even with knowledge of the name or availability of technical computing workers 270A-270N on the network 140, the technical computing client 250 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 available technical computing worker 270A-270N.
  • In FIG. 3B, the technical computing client 250 submits one or more tasks (Task1-TaskN-M) to the automatic task distribution mechanism 260. These tasks can be submitted sequentially or in an order and frequency as specified by the technical computing client 250. The automatic task distribution mechanism 260 obtains the tasks (Task1-TaskN-M) to make then available for distribution to any of the technical computing workers 270A-270N. A technical computing worker 270A-270N takes a task from the automatic task distribution mechanism 260 for technical computing of the task, computes a result for the task and provides the result to the automatic task distribution mechanism 260. For example, technical computing worker 270A takes task 1 from the automatic task distribution mechanism 260, computes a result, Result 1, for task 1, and submits Result 1 to the automatic task distribution mechanism 260. The automatic task distribution mechanism 260 makes the results (Result1-ResultN-M) available to the technical computing client 250 as they get submitted from the technical computing worker 270A-270N generating and submitting the respective result. At a time or method determined by the technical computing client 250, the technical computing client 250 obtains the results of the computed tasks from the automatic task distribution mechanism 260. For example, the technical computing client 250 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 automatic task distribution mechanism 260. Accordingly, the technical computing client 250 can determine the order and frequency of obtaining one or more of the results. As with the direct distribution mode, the technical computing workers 270A-270N can also communicate and interact with each other, as depicted by the phantom arrowed lines between the technical computing workers 270A-270N in FIG. 3B, to execute tasks both serially and in parallel by submitting a task to another technical computing worker 270A-270N.
  • The batch mode of automated task distribution embodied in system 315 of FIG. 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 automatic task distribution mechanism 260. In brief overview of the batch mode of the automatic distribution system 315, a technical computing client 250 is in communication with the job manager 265 on the server 160. The job manager 265 interfaces and communicates with the automatic task distribution mechanism 260 running on the same server 160. Each of the technical computing workers 270A-270N is in communication with the automatic task distribution mechanism 260. A job manager 265 interfaces with and is associated with one automatic task distribution mechanism 260. Alternatively, the job manager 265 and the automatic task distribution mechanism could be on different servers 160. Additionally, a plurality of job managers and automatic task distribution mechanisms could be running on a single server 160 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 the job manager 265 and the automatic distribution mechanism 260 to handle additional multiple technical computing clients 250 distributing tasks.
  • In batch mode as depicted in FIG. 3C, the technical computing client 250 defines the job. The technical computing client 250 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 in FIG. 3B, the technical computing client 250 submits the job containing all the associated tasks to the job manager 265. The job manager 265 is a software component that provides an object-oriented interface to the automatic task distribution mechanism 260. The job manager 265 obtains the tasks from the job and provides the tasks to the automatic task distribution mechanism 260 for technical computing workers 270A-270N to take and compute results. For example, technical computing client 250 defines a job, Job1, with a set of three tasks: Task1, Task2 and TaskN-M. The technical computing client 250 then submits Job1 to the job manager 265. The job manager 265 obtains Job1 and obtains each of the tasks, Task1-TaskN-M from Job 1. Then, according to the configured logic of the job manager 265, described in more detail below, the job manager 265 submits each of the tasks to the automatic task distribution mechanism 260 for technical computing by a technical computing worker 270A-270N. Technical computing worker 270A may take Task1 from the automatic task distribution mechanism 260, compute a Result1 for Task1 and provide the Result1 to the automatic task distribution mechanism 260. Technical computing worker 270B and technical computing worker 270N, in a similar fashion, compute and provide results for Task2 and TaskN-M respectively. The job manager 265 then obtains the set of results for the completed job of Job1 and provides the results of each of the tasks to the technical computing client 250.
  • The job manager 265 further comprises a queue 267 for arranging and handling submitted jobs. For example, the job manager 265 may handle jobs in a first-in first-out (FIFO) manner. In this case, the job manager 265 does not process the next job until all the tasks from the current job have been processed by the automatic task distribution mechanism 260. Additionally, the job manager 265 using the queue 267 supports handling multiple job submissions and task distribution from multiple technical computing clients 250. If a first technical computing client 250 submits a job, Job1, the job manager 265 places that job first in the queue 267. If a second technical computing client submits a second Job, for example, Job 2, the job manager places the job in the queue behind the Job1 from the first client. In this manner, all technical computing clients 250 accessing the services of the job manager 265 get serviced for task distribution. One ordinarily skilled in the art will recognize that the job manager 265 could implement a variety of algorithms for processing jobs in a job queue 267 and for handling multiple technical computing clients 250. For example, a user may be able to specify a priority level for a specified job, or the logic of the job manager 265 may make task distributing and processing decisions based on the configuration and availability of technical computing workers 270A-270B to determine a preferred or optimal selection of technical computing of jobs and tasks.
  • As with the other distribution modes of FIG. 3A and FIG. 3B, the technical computing workers 270A-270N in batch mode can also communicate and interact with each other as shown by the phantom arrowed lines between technical computing workers 270A-270N in FIG. 3C. This allows the technical computing workers 270A-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, a technical computing worker 270A can obtain information about the other technical computing workers 270B-270N assigned to or working on tasks associated with a specific job, or available on the network 140.
  • The exemplary embodiment of the batch mode of automated task distribution system 320 of FIG. 3D depicts a configuration where the job manager 265 contains the automatic task distribution mechanism 260. In brief overview of system 320, a technical computing client 250 is in communication with the job manager 265 on the server 160. The job manager 265 comprises a task distribution mechanism 260 running as part of the job manager 265 on the same server 160. The job manager 265 further comprises a queue 267 for arranging and handling submitted jobs. The technical computing workers 270A-270N are in communication with the job manager 265 to receive tasks from the automatic task distribution mechanism 260 of the job manager 265.
  • In batch mode operation as depicted in FIG. 3D, the technical computing client 250 defines the job comprised of related tasks. Instead of submitting each task separately as depicted in FIG. 3B, the technical computing client 250 submits the job containing all the related tasks to the job manager 265. The job manager 265 obtains the tasks from the job and submits the tasks, via an automatic task distribution mechanism 260, to the technical computing workers 270A-270N to perform technical computing. For example, technical computing client 250 defines a job, Job1, with a set of three tasks: Task1, Task2 and TaskN-M. The technical computing client 250 then submits Job1 to the job manager 265. The job manager 265 obtains Job1 and obtains each of the tasks, Task1-TaskN-M, from Job 1. Then, the automatic task distribution mechanism 260 of the job manager 265 submits each of the tasks to a technical computing worker 270A-270N for technical computing. For example, the job manager 265 may submit Task 1 to technical computing worker 270A to compute and produce a Result1 for Task1. Technical computing worker 270A provides the Result1 to the job manager 265. In a similar fashion, the job manager 265 may submit Task2 and TaskN-M to technical computing worker 270B and technical computing worker 270N with each technical computing worker 270A and 270B providing the results for Task2 and TaskN-M respectively to the job manager 265. When all the results from each of the tasks of Job1 are received, the job manager 265 then provides the results of each of the tasks of Job 1 to the technical computing client 250.
  • In the batch mode of operation of depicted in FIGS. 3C and 3D, the job manager 265 or automatic task distribution mechanism 260 can be configured to define the minimum and maximum numbers of technical computing workers 270A-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 the job manager 265 or automatic task distribution mechanism 260, 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 or 320) can compare the number of technical computing workers 270A-270N registered, or otherwise available, with the job manager 265 or automatic task distribution mechanism 260 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 of technical computing workers 270A-270N registered or available to work on the job. In a similar manner, the system can check the number of available or registered technical computing workers 270A-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 of technical computing workers 270A-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 of technical computing workers 270A-270A are available or registered to start the job, and may not use any more technical computing workers 270A-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 separate technical computing workers 270A-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 in FIGS. 3A-3D, the system can determine or select the technical computer worker 270A-270N to work on a task by operational and/or performance characteristics of the technical computing worker 270A-270N and/or workstation 170A-170N. For example, a technical computing worker 270A may work on a task based on the version of the MATLAB®-based distributed computing application that is installed on the workstation 170A or that the technical computing worker 270A is capable of running.
  • Additionally, the technical computing worker 270A-270N and workstation 170A-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 that specific computing device 102 of the workstation 170A. 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 the technical computing worker 270A-270N. Furthermore, the system may determine the technical computing worker 270A-270N to work on a task by any configuration or properties set on the technical computing worker 270A-270N or workstation 170A-170N. For determining a technical computing worker 270A-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 a technical computing worker 270A-270N running on a workstation 170A-170N through any interface of the technical computing worker 270A-N or workstation 170A-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 in FIGS. 3A-3C. Additionally, the distributed system 400 is depicted supporting multiple clients 250A-250N communicating with multiple job managers 265A-265N and multiple automatic task distribution mechanisms 260A-260N. With these multiple modes of operation, any technical computing client 250A-250N can distribute tasks directly to a technical computing worker 270A-270N, submit tasks to the automatic task distribution mechanism 260, or submit a job to the job manager 265. In the depicted multi-client distributed system 400, a plurality of technical computing clients 250A-250N are in communication with one or more job managers 265A-265N. The job manager 265A can be a separate component interfacing to the automatic task distribution mechanism 260A, or the job manager 265N can be a single application comprising the functionality of the automatic task distribution mechanism 260N. The one or more technical computing workers 270A-270B are in communication with the one or more job managers 265N or the one or more automatic task distribution mechanisms 260A. 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 in FIG. 4, a technical computing client 250A can operate in both the direct distribution mode and the batch automated distribution mode. As such, technical computing client 250A can submit a task to and receive a result from the automatic task distribution mechanism 260A without using the job manager 265A. In another instance, technical computing client 250A can submit a job, Job1, to the job manager 265A for task distribution by the automatic task distribution mechanism 260A to receive results from the job, such as Job1Results. In another example of FIG. 4, technical computing client 250B can operate in batch automated distribution mode but submit jobs separately to a first job manager 265A running on a first server 160A and a second job manager 265N running on a second server 160N. In yet another example, technical computing client 250N operates in both the automated distribution and direct distribution modes. Technical computing client 250N submits a task, Task2, to automatic task distribution mechanism 260N and receives a result, Task2Result, from computing by a technical computing worker 270A-270N assigned by the system 400. Technical computing client 250N also directly submits a task to technical computing worker 270N and receives a computed result directly from the technical computing worker 270N. One ordinarily skilled in the art will appreciate the various combinations of deployments that can occur with such a distributed system 400 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 to technical computing workers 270A-270N for processing, either directly, or indirectly and automatically, as described above in reference to the embodiments depicted in FIGS. 3A-3C. FIGS. 5A, 5B and 5C 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, and FIG. 5C, a batch mode method of automated distribution.
  • Referring now to FIG. 5A, one embodiment of the method 500 to distribute a task from a technical computing client 250 to a technical computing worker 270 is illustrated. Method 500 is practiced with the direct distribution embodiment of the invention depicted in FIG. 3A. The technical computing client 250 defines a task comprising an operation for technical computing (step 502). 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. The technical computing client 250 then submits the task (step 504) to the technical computing worker 270. The technical computing worker 270 receives the task (step 506) and performs the requested technical computing as defined by the task (step 508). In performing the technical computing on the task, an associated result may be generated (step 510). In alternative embodiments, either no result is generated, or no result is required to be returned to the technical computing client 250. After generating the result from computing the task, the technical computing worker 270 provides the result (step 512) to the technical computing client 250, and the technical computing client 250 obtains the result from the technical computing worker 270 (step 514).
  • Referring now to FIGS. 5B, an embodiment of the method 525 to distribute a task from a technical computing client 250 to a technical computing worker 270 in automated task distribution mode is illustrated. Method 525 is practiced with the automatic task distribution embodiment of the invention depicted in FIG. 3B. A technical computing worker 270 registers to receive notification of one or more tasks (step 527) becoming available, or appearing, in the automatic task distribution mechanism 260. The technical computing client 250 defines a task comprising an operation for technical computing (step 502). The technical computing client 250 then submits the task (step 530) to the automatic task distribution mechanism 260. The automatic task distribution mechanism 260 receives the task and makes the task available for distribution (step 532) to a technical computing worker 270. The technical computing client registers (step 534) with the automatic task distribution mechanism 260 to receive notification when a result associated with the task submitted in step 530 is available, or appears, in the automatic task distribution mechanism 260. The automatic task distribution mechanism 260 registers the technical computing client 250 for notification when the result appears (step 536). The automatic task distribution mechanism 260 provides notification (step 538) to the technical computing worker 260 of the availability of the task. In response to receiving the notification (step 540), the technical computing worker obtains (step 544) the task provided (step 540) from the automatic task distribution mechanism 260. The technical computing worker 270 performs the requested technical computing on the function or command as defined by the task (step 508). In performing the technical computing on the task, an associated result may be generated (step 510). In alternative embodiments, either no result is generated or the result is not required to be returned to the technical computing client 250. After generating the result from computing the task (step 510), the technical computing worker 270 provides the result (step 512) to the automatic task distribution mechanism 260. After obtaining the result from the technical computing worker 250 (step 550), the automatic task distribution mechanism 260 notifies (step 552) the technical computing client 250 that the result is available. The technical computing client 250 obtains (step 556) the result provided (step 558) by the automatic task distribution mechanism 260.
  • Referring now to FIGS. 5C and 5D, one embodiment of the method 560 to distribute a task from a technical computing client 250 to a technical computing worker 270 in a batch mode of operation is illustrated. Method 560 is practiced with the batch mode of the automatic task distribution system (e.g. 315 or 320). A technical computing worker 270 registers to receive notification of one or more tasks (step 527) becoming available, or appearing, in the automatic task distribution mechanism 260. In an exemplary embodiment, the technical computing worker registers to receive a task from the job manager 265 or automatic task distribution mechanism 260 as notification to perform computing on the task. The technical computing client 250 defines one or mores tasks (step 562), with one or more of the tasks comprising an operation or function for technical computing. The technical computing client 250 groups one or more tasks of the tasks into a job (step 564). The technical computing client 250 then submits the job (step 566) to the job manager 265. The job manager 265 obtains the job (step 568) from the technical computing client 250 and provides the one or more tasks of the job (step 570) to the automatic task distribution mechanism 260, which makes the one or more tasks available for distribution (step 572) to one or more technical computing workers 270A-270N. In an exemplary embodiment, the job manager 265 or the automatic task distribution mechanism 260 may submit the one or more tasks to the one or more technical computing workers 270A-270N. In another embodiment, the technical computing worker 270 may take the task from the job manager 265 or the automatic task distribution mechanism 260.
  • The technical computing client 250 registers (step 574) a callback function with the job manager 265. The technical computing client 250 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. The job manager 265 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, the job manager 265 may register (step 576) with the automatic task distribution mechanism 260 to receive notification of the results of the submitted tasks appearing in the automatic task distribution mechanism 260, or being received from the technical computing worker 270A-270N. In one embodiment, the automatic task distribution mechanism 260 registers the notification request of the job manager (step 578). Then, the automatic task distribution mechanism 260 provides notification to the technical computing worker 270 of the availability of the task (step 538). In an exemplary embodiment, the task is sent, by the job manager 265 to the technical computing worker 270 as notification to perform the task. In response to receiving the notification or the task (step 540), the technical computing worker 270 obtains (step 542) the task provided (step 540) from the automatic task distribution mechanism 260 or the job manager 265. The technical computing worker 270 performs the requested technical computing on the operation as defined by the task (step 508). In performing the technical computing on the task, an associated result may be generated (step 510). In alternative embodiments, either no result is generated or the result is not required to be returned to the technical computing client 250. After generating the result from computing the task (step 510), the technical computing worker 270 provides the result (step 510) to the automatic task distribution mechanism 260 or the job manager 265. After obtaining the result from the technical computing worker 250 (step 550), the automatic task distribution mechanism 260 notifies (step 587) the job manager 265 that the result is available. In an exemplary embodiment, the job manager 265 receives the results from the technical computing worker 270. In response to receiving the notification or the result (step 589), the job manager 265 obtains the result (step 591) provided by (step 593) the automatic task distribution mechanism 260. If the job manager 265 received the last result of the job, the job manager 265 will notify the technical computing client 250 that the job is completed via the registered callback function (step 595). After triggering the completed job callback function (step 597), the technical computing client 250 obtains (step 598) the result provided (step 599) by the job manager 265.
  • With the methods of task distribution described above ( methods 500, 525, and 560) in view of the embodiment of the concurrent multiple distribution modes of operation depicted in system 400 of FIG. 4, one ordinarily skilled in the art will recognize the application of the above methods to the multiple modes of operation for each technical computing client 250A-250N in FIG. 4.
  • FIG. 6A shows the details of one embodiment of the automation features of a technical computing client 250 and technical computing worker 270 distributing tasks and results with the automatic task distribution mechanism 260. The automatic task distribution mechanism 260 may be object-oriented and comprise an object exchange repository 662, 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 an object exchange repository 662, 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 the technical computing client 250 and the technical computing worker 270 with regards to task and result objects. By the automatic communication features described above, the technical computing client 250 does not need to specify a named technical computing worker 270 to perform technical computing. The automatic task distribution mechanism 260 comprising the object exchange repository 662 handles task distribution to technical computing workers 270A-270N registered with the automatic task distribution mechanism 260. To distribute tasks and results, the technical computing client 250 and technical computing worker 270 read and write task and result objects to the object exchange repository 662.
  • Referring now to FIG. 6A, a technical computing client 250 executes a write transaction to write a task object to the object exchange repository 662 of the automatic task distribution mechanism 260. The task object defines a task for technical computing by a technical computing worker 270 who obtains the task object from the object exchange repository 662. The technical computing client 250 registers with the object exchange repository 662 to be notified when a result object associated with the submitted task object is available in the object exchange repository 662. In this way, the technical computing client 250 can listen for the appearance of results for tasks submitted for technical computing processing. A technical computing worker 270 registers with the object exchange repository 662 to be notified when a task object appears in the object exchange repository 662. After the technical computing client 250 writes the task object, the object exchange repository 662 sends a notification to the technical computing worker 270 informing of the task object being available in the object exchange repository 662. The technical computing worker 270, in response to the notification, performs a take operation on the object exchange repository 662 to retrieve the submitted task object. The take operation removes the task from the object exchange repository 662. In the alternative, a read operation can be performed to get a copy of the task object without removing it from the object exchange repository 662.
  • The technical computing work 270 obtains the name and arguments of the function to compute from the data structure of the task object. Then the technical computing worker 270 provides the result from the computation by performing a write operation to write a result object to the object exchange repository 662. The result object defines within its data structure a result of the computation of the function defined in the task object and performed by the technical computing worker 270. The write of the result object to the object exchange repository 662 triggers the notification event registered by the technical computing client 250. The technical computing client 250 listening for the result to appear in the object exchange repository 662, in response to the notification, performs a take operation, or alternatively a read operation, to obtain the result object associated with the submitted task. The technical computing client 250 then obtains the result information defined within the data structure of the retrieved result object.
  • FIG. 6B depicts the operations of the automatic task distribution mechanism 260 interfacing with a job manager 265. In this embodiment, the job manager 265 is a software component providing a front-end interface to the automatic task distribution mechanism 260, and in this exemplary embodiment, the JavaSpace object exchange repository 662. The job manager 265 supports the batch mode of automatic task distribution operation of the invention. Under batch processing, tasks are grouped into a job in the technical computing client 250 and then the job is submitted to the job manager 265 for task distribution and task processing by a technical computing worker 270. When the job manager 265 receives a job from one or more technical computing clients 250A-250N, the job manager 265 places the job into a position in a job queue 267. The job queue 267 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. The job manager 265 handles jobs in a first-in first-out (FIFO) manner and manages the job queue 267 to first take out the job that was first received by the job manager 265 and placed into the job queue 267. For example, the job queue 267 depicted in FIG. 6B is holding the jobs of job1, job2 through jobn. Job1 is the first submitted job to the job manager 265 and is positioned at the top of the job queue 267. Job2 through JobN are the next subsequent jobs in the job queue 267 in order of a FIFO queuing system. While Job1 is being processed, the job manager 265 does not start to process the next job, Job2, until there are no tasks from the Job1 remaining to be processed in the object exchange repository 662. 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 to FIG. 6B, the technical computing client 250 submits a job to the job manager 265 and specifies a callback function with the job manager 265. The job manager 265 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 a job queue 267. The job manager 265 then obtains the one or more tasks from the first job submitted to the job queue. In the embodiment of a JavaSpace implementation of the object exchange repository 662, the job manager 265 writes the task object to the object exchange repository 662. The job manager 265 registers with the object exchange repository 662 to receive a notification when a result object associated with the task appears in the object exchange repository 662, also known as a space. The job manager 265 listens and waits for the result to appear in the object exchange repository 662.
  • A technical computing worker 270 registers with the object exchange repository 662 to receive a notification when a task object appears in the object exchange repository 662. Then the technical computing worker 270 listens for the appearance of task objects. When the task is submitted to the object exchange repository 662 by the job manager 265, the technical computing worker 270 receives a notification and takes the task from the object exchange repository 662 by performing a take operation. The technical computing worker 270 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 the technical computing worker 270 submits a result object representing a result of the task to the object exchange repository by performing a write operation. The job manager 265 waiting for the result to appear in the object exchange repository 662 receives a notification from the object exchange repository 662 that the result is available. The job manager 265 checks to see if this is the last result to be obtained from the object exchange repository 662 for the job currently being processed. If the result is the last result, the job manager 265 then notifies the technical computing client 250 that the job is completed by calling the registered callback function. In response to executing the callback function, the technical computing client 250 then interfaces with the job manager 265 to retrieve the results from the job manager 265, which the job manager 265 retrieves from the object exchange repository 662 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, the job manager 265 includes the functionality of the automatic task distribution mechanism 260. In brief overview, the technical computing client 250 is in communication with the job manager 265, which is in communication with the technical computing worker 270. The job manager comprises a job queue 267, an automatic task distribution mechanism 260, a job runner 667, a worker pool 668 and a database 669. Any of these components of the job manager 265 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.
  • The worker pool 668 contains a list of technical computing workers 270A-270N that are available to work on a task. These technical computing workers 270A-270N may on startup register with a job manager 265. The name of the job manager 265 the technical computing worker 270A-270N is associated with may be configurable by an interface of the technical computing worker 270A-270N, or by a command line startup parameter, or an external configuration or registration file. The worker pool 668 may keep a list of “good” technical computing workers 270A-270N, or those workers to which the job manager 265 can communicate with and can determine has such a status to be available for processing tasks. The job manager 265 can update the worker pool 667 by going through the list of technical computing workers 270A-270N registered in the worker pool 667 and sending communications to each of the technical computing workers 270A-270N to determine their status and if they are available. Accordingly, the worker pool 667 can be updated to determine the current set of technical computing workers 667 available, or otherwise able to receive tasks from the job manager 265.
  • The job runner 667 is responsible for determining the next task to work on and for submitting the task to a technical computing worker 270A-270N. The job runner 667 works with the job queue 267 and takes the next task for processing from a job in the job queue 267. The job runner 667 obtains from the worker pool 668 a name of or reference to a technical computing worker 270A-270N and submits the task for processing to the obtained technical computing worker 270A-270N. The job runner 667 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 the job queue 267 or any other manner based on priority, availability, task and job option settings, user configuration, etc. The job runner 667 in conjunction with the worker pool 668 and the job queue 267 can form a portion of or all of the functionality of the automatic task distribution mechanism 260. The job runner 667 can have such logic to determine from the worker pool 668 which technical computing worker 270A-270N should be assigned and sent a task from the job queue 267. Alternatively, a separate automatic task distribution mechanism 260 can be responsible for determining the technical computing worker 270A-270N to be assigned a task and to send the task to the assigned technical computing worker 270A-270N. In any of these embodiments, the technical computing worker 250 does not need to know the identity, such as via a hostname or an internet protocol address, of the technical computing worker 270A-270N assigned to perform technical computing on a task.
  • The job manager 265 also has a database 669 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 the job queue 267, the list of workers of the worker pool 668, the tasks of any jobs in the job queue 267, the properties of any of the task, job or job manager objects may be stored in the database 669. The database 669 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. The database 669 can be an in process database 669 of the job manager 265 or it can be a remote database 669 available on another computing device 102′ or another server 260′. Furthermore, each instance of the job manager 265A-265N could use a different database and operating system than other instances of the job manager 265A-265N, or be using a local database while another job manager 265A-265N uses a remote database on another server 160′. One ordinarily skilled in the art will appreciate the various deployments of local or remote database access for each of the one or more job managers 265A-265N.
  • The job manager 265 can be configured to execute certain functions based on changes of the state of a job in the queue 267. For example, the technical computing client 250 can setup functions to be called when a job is created in a job queue 267, when the job is queued, when a job is running or when a job is finished. The job manager 265 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 to FIG. 6C, the technical computing client 250 submits a job, Job1, comprised of one or more tasks, such as Task 1 and Task2, to the job manager 265. The job manager receives the job, e.g., job1, and places the job into a job queue 267. The job runner 667 then obtains the one or more tasks from the first job submitted to the job queue 267. A technical computing worker 270 registers with the job manager 265 and is listed in the worker pool 668 of the job manager 265. From the worker pool 668, the job runner 667 determines a technical computing worker 270A-270N to submit the task for processing. The technical computing worker 270A-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 the technical computing worker 270 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 the technical computing worker 270A-270N updated to indicate any error conditions in performing the task or executing the function of the task. The job manager 265 checks to see if this is the last result to be obtained from a technical computing worker 270A-270N for the job currently being processed. If the result is the last result, the job manager 265 can provide the set of task results for the completed job to the technical computing client 250.
  • Although the invention is generally discussed in terms of a job manager 265, automatic task distribution mechanism 260 and technical computing worker 250 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 to FIG. 7, an exemplary embodiment of the invention is shown implementing a service oriented approach with Jini network technology. In broad overview of the system 700, the technical computing client 250, technical computing workers 270A-270N, job managers 265A-265N, automatic task distribution mechanisms 260A-260N are in communication over the network 140 via network communication channels 130. Additionally there is a network server 760 in communication with the network 140 through the network communication channel 130. The network server 760 hosts a code base server 710. In an exemplary embodiment, the code base server 710 is an ftp server. In other embodiments, the code base server 710 is a web server, such as Java web server, or an http server. The code base server 710 is capable of and configured to upload files, including class or interface files. In an exemplary embodiment, the code base server 710 may upload JAR files. The code base server 710 may be available on the network 140 to Jini based services to obtain class files as a service on the network 140 may need, or it may be available to a technical computing client 250 to determine the interface to a service on the network 140.
  • In support of implementing software components of the present invention as Jini services, one or more of the following Jini services are available on the network server 760 on the network 140: Reggie 718, Mahalo 716, Fiddler 714 and Norm 712. These services are part of the Sun Technology Jini network technology implementation. Reggie 718 is a Jini service that provides service registration and discovery. This allows clients of a service to find the service on the network 140 without knowing the name of the computing device the service is running on. Mahalo 716 is a transaction manager service that provides fault tolerant transactions between services and clients of the service accessing the service. Fiddler 714 is a lookup discovery service. A Jini based service needs to register itself with an instance of Reggie in order to be discoverable on the network 140. The lookup discovery service of Fiddler 714 allows the service to find new Reggie services and register with them while inactive. Norm 712 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 any computing device 102 on the network 140 capable of running these services and can be run on a single java virtual machine (JVM).
  • Referring again to FIG. 7, the technical computing workers 270A-270N, which provide MATLAB® sessions, are made available as Jini Services to support the direct task distribution mode of operation of the invention. The technical computing workers 270A-270N register with a lookup service such as Reggie 718. This allows the technical computing workers 270A-270N to be discoverable on the network 140 by a technical computing client 250 without the technical computing client 250 knowing information like the host name of the workstations 170A-170N the technical computing workers 270A-270N are running on, or the port number to which a specific technical computing worker 270A-270N service is listening on, or a worker name associated with a technical computing worker 270A-270N.
  • The technical computing workers 270A-270N also support service activation with an activation daemon 740A-740N software component. Activation allows a technical computing worker service 270A-270N to register with an activation daemon 740A-740B to exit and become inactive, but still be available to a technical computing client 250. In all three distribution modes of operation as embodied in FIGS. 3A-3C, the MATLAB®-based technical computing workers 270A-270N can be activated by an activation daemon 740A-740N. This means that an activation daemon 740A-740N starts and stops the technical computing worker 270A-270N. For example, the technical computing worker 270A service registers with the activation daemon 740A on workstation 170A. The technical computing worker 270A includes the activation states of active, inactive and destroyed. In the active state, the technical computing worker 270A is started and is available for remote method calls from a technical computing client 250. 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, the technical computing client 250 is not started, but is still available for remote method calls from a technical computing client 250. If a remote method call to the technical computing worker service 270A is made by the technical computing client 250, the technical computing worker service 270A will be started by the activation daemon 740A, and the method call will be executed by the technical computing worker service 270A. In the destroyed state, the technical computing worker service 270A is not running and is not registered with the activation daemon 740A. In this state, the technical computing worker service 270A is not available for remote calls from a technical computing client 270. As such, the activation daemons 740A-740N provide persistence and maintain the state of the technical computing worker services 270A-270N.
  • The activation feature of technical computing worker services 270A-270N saves computing resources on workstations hosting the technical computing worker, and also increases service reliability. For example, if the technical computing worker service 270A terminates abruptly, the activation daemon 740A will automatically restart the next time a call is made to it. The activation daemon 740A-740N also provides for the graceful termination of the technical computing worker service 270A-270N. If an inactivate command is sent to a technical computing worker service 270A-270N, the technical computing worker service 270A-270N can complete the processing of outstanding method calls before terminating. Alternatively, a command can be sent to the technical computing worker 270A-270N to force immediate termination in the middle of processing a task. Additionally, in one embodiment, a technical computing worker 270A can be configured and controlled to shutdown after the completion of processing of a task. If the technical computing worker 270A 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 technical computing worker services 270A-270N can default to a non-debug mode when the technical computing worker service 270A-270N is started, either by the activation daemon 740A-740N or by other conventional means. Alternatively, the activation daemon 740A-740N and/or the technical computing worker service 270A-270N can be configured to start in debug mode, giving access to command line interface of the technical computing worker 270A-270N.
  • In a manner similar to technical computing worker services 270A-270N, the job managers 265A-265N and automatic task distribution mechanisms 260A-260N as depicted in FIG. 7 can also be implemented as services. As such, the job managers 265A-265N and automatic task distribution mechanisms 260A-260N can support lookup registration and discovery so that a technical computing client 250A can find the service without knowing the associated name of the service, the host name of the server 160 running the service, or the port name the service is listening on. Additionally, the job manager 265A-265N and automatic task distribution mechanism services 260A-260N can be supported by activation daemons as with the technical computing worker services 270A-270N.
  • In another aspect of the invention, the services of the technical computing worker 270A-270N, job manager 265A-265N and the automatic task distribution mechanism 260A-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 in FIG. 7, the technical computing workers 270A-270N may each include a technical computing worker administration software component 740A-740B, the job managers 265A-265N may each include a job manager administration software component 730A-730B, and the automatic task distribution mechanisms 260A-260N may also each include an administration software component 760A-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 the technical computing client 250, and may be configured to only be available to system administrators or to those users with certain access rights to such functionality.
  • For example, the administration component 760A of the automatic task distribution mechanism 260A 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 repository 664, or space, as described in the user defined data classes below.
  • In another example, the job manager administration component 730A may provide a graphical view of all the jobs in the job queue 267 of the job manager 265. 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 the queue 267. 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 manager 266 as described in the user defined data classes below.
  • A graphical user interface to the technical computing worker administration component 750A-750N may provide a user the ability to change the activation state, stop and start, or debug the technical computing worker service 270A-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 the technical computer worker 270A-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 distributed system 800 embodiment of the present invention, the system 800 makes use of task objects 810, result objects 812, job objects 814 and jobresults objects 816 These objects present a lower level user interaction mechanism to interact with the task distribution functionality of the system 800.
  • In the object-oriented distributed system 800 of FIG. 8A, the technical computing client 250 creates or declares a task object 810. The task object 810 is a user defined data class containing a MATLAB® command, input data and number of arguments. The technical computing client 250 submits the task object, in the automated mode of operation, to the automatic task distribution mechanism 260, which stores the task object 810 in the object exchange repository 662. A technical computing worker 270 listening and waiting for a task object 810 to appear in the object exchange repository 662, takes the task object 810 to perform technical computing of the task. The technical computing worker 270 obtains the MATLAB® command and arguments from the properties of the task object 810 and performs technical computing on the task in accordance with the command. The technical computing worker 270 then creates or specifies a result object 812, which is a user defined data object containing the output data resulting from the execution of a task represented by a task object 810. The technical computing worker 270 then writes the result object 812 to the object exchange repository 662. The technical computing client 250 listens and waits for the appearance of the result object 812 in the object exchange repository 662. After the result object 812 appears in the object exchange repository, the technical computing client 250 takes the result object 812 from the object exchange repository and retrieves result information from the properties of the result object 812.
  • Referring still to FIG. 8A, in batch mode, the technical computing client 250 creates or declares a job object 814, which is a user defined data object containing an array of task objects 810. The technical computing client 250 then submits the job object 814 to the job manager 265 for processing. The job manager 265 then submits the one or more task objects 820 defined in the job object 814 to the object exchange repository 662 for processing by a technical computing worker 270. The technical computing worker 270 listening for the appearance of the task objects 820, takes the task objects 820 and performs technical computing on the function as defined by each task object. The technical computing worker 270 then generates results and creates or specifies the result objects 822 representing the output generated for each function of each of the task objects 820 of the job object 814. The technical computing worker 270 then writes the result objects 822 to the object exchange repository 662. The job manager 662 listening for the appearance of the result objects 822 takes the result objects from the object exchange repository 662. The job manager 265 then creates or specifies the jobresults object 816, which in an object that provides an array of result objects 844 for each task object defined in a job object 814. The job manager then provides the jobresults object 816 to the technical computing client 250. 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 in FIG. 4.
  • In an embodiment of the invention as depicted in FIG. 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:
  • Task Properties
  • 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
  • Result Properties
  • 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
  • Worker Properties
  • 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
  • WorkerAdmin Properties
  • 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)
  • Space Properties
  • 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
  • SpaceAdmin Properties
  • 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
  • Job Properties
  • 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
  • JobResults Properties
  • 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
  • JobManager Methods
  • 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
  • JobManagerAdmin Properties
  • 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 of technical computing workers 270A-270N, automatic task distribution mechanisms 260A-260N, or spaces, and job managers 265A-265N as depicted in FIG. 7. With these methods, a technical computing client 250 does not need to have previous knowledge of any technical computing worker 270A-270N, any of the automatic task distribution mechanisms 260A-260N or any job managers 265A-265N. The technical computing client 250 can use these methods to discover the name and number of such services available on the network 140.
  • In an embodiment of the present invention, the programming language of MATLAB® may support the three modes of operation as described with FIGS. 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 distributed system 805 of FIG. 8B, the technical computing client 250 creates or declares a job object 860 residing in the job manager 265. The job object comprises one or more task objects 870A-870N. The job object 860 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 object 870A-870N is an object that defines a function to be executed by a technical computing worker 270. The function contains a MATLAB® command, input data and number of arguments. The task object 870A-870N defines additional task properties, such as those defined below. For example, the task object 870A-870N may have a state property to indicate the current state of the task. Additionally, the technical computing client 250 may interface with the job manager 265 through a job manager object 865 residing on the job manager 265. In a similar manner to the job object 860 and task objects 870A-870N, the job manager object 865 may have properties to define configuration and other details about the job manager 265 as described below. For example, the job manager object 865 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 the job manager object 865, job object 860 or task objects 870A-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 the job manager 265.
  • Still referring to FIG. 8B, the technical computing client 250 submits the job to the job manager 265 via the job object 865. The job manager 265 obtains each of the task objects 870A-870N from the job object 865. The job manager puts the job of the job object 860 into the job queue 267. The job runner 667 obtains the one or more task objects 870A-870N from the job object 860. The job runner 667 with the worker pool 668 determines a technical computing worker 270 to process a task. The job runner 667 then submits a task, via a task object 870A-870N to an assigned technical computing worker 270. The technical computing worker 270 obtains the function to execute from the properties of the task object 870A-870N and performs technical computing of the task in accordance with the function. The technical computing worker 270 then obtains the results of the function and updates one or more properties of the task object 870A-870N with information about the results. In the case of any errors, the technical computing worker 270 may update any error properties of the task object 870A-870N. In a similar manner as the technical computing client 250, the technical computing worker 270 may use proxy or facade objects to interface with the job 860, job manager 865 or task 870A-870N objects residing in the job manager 265. The job manager 265 then updates the job object 860 with updated task objects 870A-870N containing the results of each task. The job manager 265 may also update other properties of the job object 860, such as start and finish times of the job, to reflect other information or status of the job. The job manager 265 then provides the updated job object 860 to the technical computing client 250. The technical computing client 250 then can retrieve the results of each task from the updated job object 860. 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 in FIG. 4.
  • In an exemplary embodiment of the invention as depicted in FIG. 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 Reference Job 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 in FIGS. 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 to FIG. 9A, the distributed system 910 supports the delegation of tasks from a technical computing client 250 to remote technical computing workers 270A-270N leveraging the processing capability of each of the workstations 170A-170N hosting each of the technical computing workers 270A-270N. The tasks are executed independently of each other and do not require the technical computing workers 270A-270B to communicate with each other.
  • Still referring to FIG. 9A, the streaming, or serial, processing system 910 allows serial processing to occur via multiple technical computing workers 270A-270N on multiple workstations 170A-170N. A technical computing client 250A submits a job requiring a task to be processed serially from technical computing worker 270A to technical computing worker 270B then to technical computing worker 270N. When technical computing worker 270A completes its technical computing of the task, technical computing worker 270A submits the task to technical computing worker 270B for further processing. In a similar fashion, the task can be submitted to additional technical computing workers 270N for further processing until the task is complete in accordance with its task definition. The last technical computing worker 270N to perform technical computing on the task submits the result to the technical computing client 250.
  • The streaming processing system 920 can take advantage of specific workstations 170A-170N that may have faster processors for performing processor intensive portions of technical computing of the task or take advantage of technical computing workers 270A-270N with access to specific data sets or external control instrumentation as required for computation of the task.
  • In FIG. 9B, a parallel system 930 is depicted which combines the distributed and streaming configuration of the systems (900 and 910) in FIG. 9A. In brief overview, technical computing workers 270A and 270B and 270N 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 worker 270A can submit a task for further processing to technical computing worker 270B, and in turn, technical computing worker 270B can submit the task for further processing by technical computing worker 270N. The technical computing worker 270N when it completes processing may return a result back to the automatic task distribution mechanism 260 or the technical computing client 250. 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 distributed system 1000 in the distributed computing environment. The instrument-based distributed computing system 1000 may include one or more clients 150, servers 160, workstations 170 and instruments 180 coupled to a network 140. The client 150, server 160 and workstation may run the technical computing client 250, the automatic distribution mechanism 260 and the technical computing worker, respectively, as described above with reference to FIGS. 1A-9B. The instrument 180 may run the technical computing client 250 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 to FIGS. 12A-12C. Those skilled in the art will appreciate that the instrument-based distributed system 1000 is illustrative and may not include all of the client 150, server 160, workstation 170 and instrument 180. The instrument-based distributed system 1000 can be implemented with a various combinations of the client 150, server 160, workstation 170 and instrument 180 in other embodiments.
  • In the illustrative embodiment of FIG. 10, the client 150, server 160, workstation 170 and instrument 180 are coupled to the network 140. The client 150 or instrument 180 may communicate directly with the workstation 170 or other instruments 180 as described above with reference to FIG. 3A. The client 150 or instrument 180 may communicate with the workstation 170 or other instruments 180 via the server 160, which runs the automatic task distribution mechanism 260, as described above with reference to FIGS. 3B-4. The workstations 170 or instruments 180 may or may not communicate with each other depending on the communication topology of the distributed computing system 1000, as described above with reference to FIGS. 9A and 9B.
  • FIG. 11 is a block diagram showing an exemplary instrument utilized in the illustrative embodiment of the present invention. The instrument 180 may include instrumentation functionalities 1110, a technical computing client 250, a technical computing worker 270, an operating system 1120 and a network interface 118. The instrumentation functionalities 1110 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, the instrument 180 refers to any tool that includes one or more instrumentation functionalities.
  • The technical computing client 250 and the technical computing worker 270 installed on the instrument 180 may include the MATLAB®-based distributed computing application 120 as described above with reference to FIGS. 2A-2C. The technical computing client 250 creates a job including one or more tasks. The technical computing client 250 distributes the job to the technical computing workers for the distributed execution of the job. The technical computing worker 270 performs technical computing tasks defined by the client 250. The instrument 180 may include the technical computing client 250 and/or the technical computing worker 270. If the instrument 180 is installed with the technical computing client 250, the instrument 110 may operate to generate a job and distribute the job to workstations 170 and/or other instruments 180, as the client 150 does. If the instrument 180 is installed with the technical computing worker 270, the instrument 110 may operate to receive and execute the tasks, as the workstations 170 do.
  • The instrument 180 may include an operating system 1130 that enables users to install their own applications, such as the technical computing client 250 and the technical computing worker 270. The operating system 1130 enables the applications to run on the instrument 180. The instrument 180 may have, for example, a standard Windows® operating system so that the users can install their own applications on the instrument 180. The Windows operating system is an exemplary operating system that can be included in the instrument 180 and the operating system 1130 may include any other operating systems described above with reference to FIG. 1A.
  • The instrument 180 may communicate with the client 150, server 160, workstation 170 or other instruments 180 via the network interface 118. The network interface 1130 may include any network interfaces described above with reference to FIG. 1A. The network interface 118 may include a bus interface, such as a general purpose interface bus (GPIB) interface. The network interface 1140 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 interface 1140 may include an LXI (LAN extension for instrumentation) interface, which is based on industry standard Ethernet technology.
  • The instrument 180 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, the instrument 180 may have multiple processors or CPUs to run the workers.
  • The instrument 180 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 the client 150, workstations 170 and instruments 180 coupled to the network 140. The technical computing client 250 runs on the client 150. The technical computing the technical computing workers 270 may run on the workstations 170 and instruments 180. The technical computing client 250 creates a job and distributes the job to the technical computing workers 270 on the workstations 170 and instruments 180. The technical computing workers 270 on the workstations 170 and instruments 180 execute the job and return the execution results to the technical computing client 250 on the client 150. 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 to FIG. 10.
  • FIG. 12B is a block diagram showing another exemplary instrument-based distributed computing system. The instrument-based distributed computing system may include workstations 170 and instruments 180 coupled to the network 140. The technical computing client 250 runs on the instrument 180. The technical computing workers 270 run on the workstations 170 and other instruments 180. The technical computing client 250 creates a job and distributes the job to the technical computing workers 270 on the workstations 150 and instruments 180. The technical computing workers 270 on the workstations 170 and instruments 180 execute the job and return the execution results to the technical computing client on the client 150. 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 to FIG. 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 the client 150, workstation 170 and instrument 180 coupled to the network 140. The system may also include a sub-cluster 190 coupled to the network 140. The sub-cluster 190 may include clients, servers, workstations and instruments. The sub-cluster 190 may run additional technical computing clients and technical computing workers to distribute and execute the job defined by the technical computing client 250 on the client 150 or instrument 180. The technical computing client 250 may create a job and distribute the job to the sub-cluster 190. The technical computing workers in the sub-cluster 190 execute the job and return the execution results to the technical computing client 250 on the client 150 or instrument 180. The sub-cluster 190 may include a distribution mechanism for distributing the job to the workstations and instruments in the sub-cluster 190.
  • 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 the technical computing client 250 and the technical computing worker 270, 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 a test environment 1200 provided in the illustrative embodiment of the present invention. In the test environment 1200, various types of resources 1210 may be used for providing units under test 1230. One of skill in the art will appreciate that the resources 1210 may include software tools and hardware tools. The test environment 1200 may include a test manager 1220. Using the test manager 1220, users may input control data 1240 for setting conditions for testing the units under test 1230 in the test environment 1200. The control data 1240 may include a sequence of test steps that specifies the ordering of the resources to be used by the test manager 1220. The users may also input the variables and parameters of the test that can be used as arguments to call the functions provided by the resources 1210. Using different variables and parameters in the test, the functions of the units under test 1230 may return different values. The units under test 1230 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 under test 1230 may include software tools and hardware tools. The test manager 1220 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 under test 1230. 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 the test manager 120. 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. The client 150 defines a test for testing units under test (step 1302). The test may be defined to include one or more test steps. Each test step may test different units under test. The client 150 then submits at least a portion of the test (step 1304) to an instrument 180 or workstation 170 that contains the technical computing worker 270. For example, the client 150 then submits each test step to different workstations 170 and/or instruments 180. The technical computing worker 270 receives at least a portion of the test (step 1306) and performs the requested technical computing as defined by the test (step 1308). In performing the technical computing on the test, an associated result may be generated (step 1310). In alternative embodiments, either no result is generated, or no result is required to be returned to the client 150. After generating the result from computing the test, the workstations 170 and/or instruments 180 provide the result (step 1312) to the client 150, and the client 150 obtains the result from the workstations 170 and/or instruments 180 (step 1314). 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 to FIGS. 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 to FIGS. 6A-9B.
  • One of ordinary skill in the art will appreciate that the instrument 180 may be used as a technical computing client and/or worker and as an instrumentation tool. In one illustrative embodiment, the instrument 180 may be used as an instrumentation tool performing part of the test that acts on the information collected by the instrument 180. In another embodiment, the instrument 180 may be used as a pure technical computing client or worker utilizing the technical computing functionality of the instrument 180. In still another embodiment, the instrument 180 may be used as both a technical computing client/worker and an instrumentation tool. In this embodiment, the instrument 180 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 the instrument 180 is used as both a technical computing client/worker and an instrumentation tool, the technical computing functionality and the instrumentation functionality of the instrument 180 may need to be compromised depending on the capability of the instrument 180 to support for both of the functionalities concurrently. One exemplary way to compromise these functionalities is to pause/stop the technical computing functionality when the instrument 180 is needed to make a measurement. When the measurement is completed, the instrument 180 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 the instrument 180 can allow users to utilize the additional computational power in the instrument 180 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 which workers 270 are not currently executing a program or which workers 270 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 the computing device 102 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 assigned column 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 on column 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 on column 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 in FIG. 15. In the flow diagram of FIG. 15, method 1500 depicts the processing of a distributed array in execution in multiple workers. At step 1502, a worker is executing a program flow of a program (job or test) invoked for execution. At some point during the program flow, the worker 270 at step 1504 interprets a distributed array construct in a program statement, such as a program statement comprising the keyword darray. At step 506, the worker 270 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, the worker 270 may store a specific column of the array to perform local processing. After determining and storing the portion of the distributed array, the worker 270 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, the worker 270 may access or obtain data values of other portions of the array that have been cached. Although method 1500 is discussed with regards to one worker, the same flow diagram will apply to multiple workers 270 running the same program so that at steps 1504, 1506 and 1508 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 of claim 1, wherein at least one of the plurality of technical computing workers is a second instrument.
3. The method of claim 2, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
4. The method of claim 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 of claim 4, wherein the test equipment accelerates execution of a measurement, analysis, verification or validation of the test.
6. The method of claim 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 of claim 1, wherein the first instrument includes technical computing functionality and an instrumentation functionality for making a measurement.
8. The method of claim 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 of claim 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 of claim 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 of claim 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 of claim 12, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
14. The method of claim 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 of claim 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 of claim 12, wherein the technical computing client is a second instrument.
17. The method of claim 16, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
18. The method of claim 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 of claim 18, wherein the test equipment accelerates execution of a measurement, analysis, verification or validation of the test.
20. The method of claim 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 of claim 21, wherein at least one of the plurality of technical computing workers is a second instrument.
23. The non-transitory medium of claim 22, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
24. The non-transitory medium of claim 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 of claim 24, wherein the test equipment accelerates a measurement, analysis, verification or validation of the test.
26. The non-transitory medium of claim 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 of claim 21, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
28. The non-transitory medium of claim 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 of claim 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 of claim 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 of claim 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 of claim 32, wherein the first instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
34. The non-transitory medium of claim 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 of claim 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 of claim 32, wherein the technical computing client is a second instrument.
37. The non-transitory medium of claim 36, wherein the second instrument has a technical computing functionality and an instrumentation functionality for making a measurement.
38. The non-transitory medium of claim 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 of claim 38, wherein the test equipment accelerates a measurement, analysis, verification or validation of the test.
40. The non-transitory medium of claim 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.
US13/045,243 2005-12-12 2011-03-10 Instrument-based distributed computing systems Abandoned US20110167425A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/045,243 US20110167425A1 (en) 2005-12-12 2011-03-10 Instrument-based distributed computing systems

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/301,061 US7908313B2 (en) 2004-07-21 2005-12-12 Instrument-based distributed computing systems
US13/045,243 US20110167425A1 (en) 2005-12-12 2011-03-10 Instrument-based distributed computing systems

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/301,061 Continuation US7908313B2 (en) 2004-07-21 2005-12-12 Instrument-based distributed computing systems

Publications (1)

Publication Number Publication Date
US20110167425A1 true US20110167425A1 (en) 2011-07-07

Family

ID=37865304

Family Applications (3)

Application Number Title Priority Date Filing Date
US11/301,061 Expired - Fee Related US7908313B2 (en) 2004-07-21 2005-12-12 Instrument-based distributed computing systems
US11/880,545 Pending US20080021951A1 (en) 2004-07-21 2007-07-23 Instrument based distributed computing systems
US13/045,243 Abandoned US20110167425A1 (en) 2005-12-12 2011-03-10 Instrument-based distributed computing systems

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US11/301,061 Expired - Fee Related US7908313B2 (en) 2004-07-21 2005-12-12 Instrument-based distributed computing systems
US11/880,545 Pending US20080021951A1 (en) 2004-07-21 2007-07-23 Instrument based distributed computing systems

Country Status (4)

Country Link
US (3) US7908313B2 (en)
EP (1) EP1960877A2 (en)
JP (1) JP5442999B2 (en)
WO (1) WO2007070491A2 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120154849A1 (en) * 2010-12-20 2012-06-21 Konica Minolta Business Technologies, Inc. Image forming apparatus
US20130117751A1 (en) * 2011-11-09 2013-05-09 Jerome F. Duluk, Jr. Compute task state encapsulation
US20130263090A1 (en) * 2012-03-30 2013-10-03 Sony Online Entertainment Llc System and method for automated testing
US20130268937A1 (en) * 2012-04-09 2013-10-10 Samsung Electronics Co., Ltd. Distributed processing system, scheduler node and scheduling method of distributed processing system, and program generation apparatus thereof
US20140157242A1 (en) * 2012-12-05 2014-06-05 The Mathworks, Inc. Deferred evaluation and presentation of a custom diagnostic analysis
US20140351362A1 (en) * 2011-11-02 2014-11-27 Hitachi, Ltd. Computer system, data transfer method, and data transfer program
US8910186B2 (en) * 2011-11-15 2014-12-09 International Business Machines Corporation Feed-based promotion of service registry objects
US9104665B1 (en) * 2011-04-20 2015-08-11 Google Inc. Data backup in a graph processing system
US9269063B2 (en) 2011-09-23 2016-02-23 Elwha Llc Acquiring and transmitting event related tasks and subtasks to interface devices
US20160054774A1 (en) * 2014-08-22 2016-02-25 Intel Corporation Profiling a job power and energy consumption for a data processing system
US9858137B2 (en) 2013-12-04 2018-01-02 Exfo Inc. Network test system
US11036603B1 (en) * 2011-07-15 2021-06-15 Scale Computing Inc Distributed test suite tools
CN116860487A (en) * 2023-09-04 2023-10-10 南京国睿信维软件有限公司 Matlab integrated scheduling method based on RMI technology

Families Citing this family (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7415516B1 (en) * 2000-08-08 2008-08-19 Cisco Technology, Inc. Net lurkers
US20060075408A1 (en) * 2004-10-06 2006-04-06 Digipede Technologies, Llc Distributed object execution system
JP2006155187A (en) * 2004-11-29 2006-06-15 Sony Corp Information processing system, information processor and processing method, storage medium and program
US8621425B1 (en) * 2005-04-08 2013-12-31 The Mathworks, Inc. Generating code based at least on one or more output arguments designated as not being present
US20070033247A1 (en) * 2005-08-02 2007-02-08 The Mathworks, Inc. Methods and system for distributing data to technical computing workers
US7681087B2 (en) * 2005-12-14 2010-03-16 Business Objects Software Ltd. Apparatus and method for persistent report serving
KR100677635B1 (en) * 2006-02-02 2007-02-02 삼성전자주식회사 Method and system for controlling device in network, and recording medium storing program for performing the method thereof
US8082289B2 (en) 2006-06-13 2011-12-20 Advanced Cluster Systems, Inc. Cluster computing support for application programs
US8327350B2 (en) * 2007-01-02 2012-12-04 International Business Machines Corporation Virtual resource templates
US8108855B2 (en) * 2007-01-02 2012-01-31 International Business Machines Corporation Method and apparatus for deploying a set of virtual software resource templates to a set of nodes
US8799871B2 (en) * 2007-01-08 2014-08-05 The Mathworks, Inc. Computation of elementwise expression in parallel
US10055468B2 (en) * 2007-04-30 2018-08-21 Wolfram Research, Inc. Access to data collections by a computational system
US8370802B2 (en) 2007-09-18 2013-02-05 International Business Machines Corporation Specifying an order for changing an operational state of software application components
US8762999B2 (en) * 2007-09-27 2014-06-24 Oracle America, Inc. Guest-initiated resource allocation request based on comparison of host hardware information and projected workload requirement
DE102007062974B4 (en) * 2007-12-21 2010-04-08 Phoenix Contact Gmbh & Co. Kg Signal processing device
TWI353138B (en) * 2007-12-28 2011-11-21 Accton Technology Corp A job management and a scheduling method of networ
US20090222818A1 (en) * 2008-02-29 2009-09-03 Sap Ag Fast workflow completion in a multi-system landscape
US8331901B2 (en) * 2009-01-28 2012-12-11 Headwater Partners I, Llc Device assisted ambient services
US7827438B2 (en) * 2008-06-10 2010-11-02 Microsoft Corporation Distributed testing system and techniques
US8108467B2 (en) * 2008-06-26 2012-01-31 International Business Machines Corporation Load balanced data processing performed on an application message transmitted between compute nodes of a parallel computer
CN101296199A (en) * 2008-06-27 2008-10-29 腾讯科技(深圳)有限公司 Method for instant communication tool scheduling task, and instant communication tool
US9910708B2 (en) * 2008-08-28 2018-03-06 Red Hat, Inc. Promotion of calculations to cloud-based computation resources
US8387064B2 (en) 2008-10-09 2013-02-26 International Business Machines Corporation Balancing a data processing load among a plurality of compute nodes in a parallel computer
JP5393304B2 (en) * 2009-07-09 2014-01-22 富士通株式会社 Distributed processing system, information processing apparatus, and distributed processing method
US9323582B2 (en) 2009-08-12 2016-04-26 Schlumberger Technology Corporation Node to node collaboration
US10115065B1 (en) 2009-10-30 2018-10-30 Verint Americas Inc. Systems and methods for automatic scheduling of a workforce
US8874745B2 (en) * 2010-03-26 2014-10-28 Fujitsu Limited Method and system for providing services
US10853744B2 (en) 2010-06-17 2020-12-01 Figure Eight Technologies, Inc. Distributing a task to multiple workers over a network for completion while providing quality control
US11023859B2 (en) 2010-06-17 2021-06-01 CrowdFlower, Inc. Using virtual currency to compensate workers in a crowdsourced task
WO2012049794A1 (en) * 2010-10-14 2012-04-19 日本電気株式会社 Distributed processing device and distributed processing system
US8639971B1 (en) 2011-02-17 2014-01-28 Scale Computing Condition detection and reporting in complex systems
US8738830B2 (en) 2011-03-03 2014-05-27 Hewlett-Packard Development Company, L.P. Hardware interrupt processing circuit
US9189283B2 (en) * 2011-03-03 2015-11-17 Hewlett-Packard Development Company, L.P. Task launching on hardware resource for client
US9645823B2 (en) 2011-03-03 2017-05-09 Hewlett-Packard Development Company, L.P. Hardware controller to choose selected hardware entity and to execute instructions in relation to selected hardware entity
US11087247B2 (en) 2011-03-23 2021-08-10 Figure Eight Technologies, Inc. Dynamic optimization for data quality control in crowd sourcing tasks to crowd labor
US20120254965A1 (en) * 2011-04-04 2012-10-04 Lansing Arthur Parker Method and system for secured distributed computing using devices
US8972997B2 (en) 2011-06-17 2015-03-03 Microsoft Technology Licensing, Llc Work item processing in distributed applications
US8554605B2 (en) 2011-06-29 2013-10-08 CrowdFlower, Inc. Evaluating a worker in performing crowd sourced tasks and providing in-task training through programmatically generated test tasks
WO2013003861A2 (en) * 2011-06-30 2013-01-03 CrowdFlower, Inc. Evaluating a worker in performing crowd sourced tasks and providing in-task training through programmatically generated test tasks
US8949305B1 (en) * 2011-07-15 2015-02-03 Scale Computing, Inc. Distributed dynamic system configuration
WO2013052801A1 (en) * 2011-10-05 2013-04-11 Hartigen Solutions, Llc Integrated software development and deployment architecture and high availability client-server systems generated using the architecture
US20130091197A1 (en) 2011-10-11 2013-04-11 Microsoft Corporation Mobile device as a local server
US8626545B2 (en) 2011-10-17 2014-01-07 CrowdFlower, Inc. Predicting future performance of multiple workers on crowdsourcing tasks and selecting repeated crowdsourcing workers
US8918509B1 (en) * 2011-12-20 2014-12-23 The Mathworks, Inc. Dynamic arbitrary data simulation using fixed resources
KR101335711B1 (en) * 2012-01-20 2013-12-04 연세대학교 산학협력단 A server, An arithmatic processing method and a system thereof
DE102012203252A1 (en) 2012-03-01 2013-09-05 Rohde & Schwarz Gmbh & Co. Kg Device and method for testing electronic devices with a spatially separated control device
US11568334B2 (en) 2012-03-01 2023-01-31 Figure Eight Technologies, Inc. Adaptive workflow definition of crowd sourced tasks and quality control mechanisms for multiple business applications
JP5999351B2 (en) * 2012-03-26 2016-09-28 日本電気株式会社 Database processing apparatus, method, program, and data structure
US8972543B1 (en) * 2012-04-11 2015-03-03 Spirent Communications, Inc. Managing clients utilizing reverse transactions
US9077665B1 (en) 2012-05-24 2015-07-07 Scale Computing, Inc. Transferring virtual machines and resource localization in a distributed fault-tolerant system
US9176769B2 (en) * 2012-06-29 2015-11-03 Microsoft Technology Licensing, Llc Partitioned array objects in a distributed runtime
US10430216B1 (en) 2012-08-23 2019-10-01 Scale Computing Inc Virtual machine automated selection
US10019287B1 (en) 2012-08-23 2018-07-10 Scale Computing Virtual machine resource display
EP2744173B1 (en) * 2012-10-26 2018-08-15 Huawei Device (Dongguan) Co., Ltd. Multiple-service processing method and browser
US9600351B2 (en) 2012-12-14 2017-03-21 Microsoft Technology Licensing, Llc Inversion-of-control component service models for virtual environments
US20140201709A1 (en) * 2013-01-15 2014-07-17 Martin Carl Euerle JavaScript™ Deployment Build Tool for software code that uses an object literal to define meta data and system code.
US9146777B2 (en) 2013-01-25 2015-09-29 Swarm Technology Llc Parallel processing with solidarity cells by proactively retrieving from a task pool a matching task for the solidarity cell to process
US8893155B2 (en) 2013-03-14 2014-11-18 Microsoft Corporation Providing distributed array containers for programming objects
US9280372B2 (en) 2013-08-12 2016-03-08 Amazon Technologies, Inc. Request processing techniques
US9348634B2 (en) 2013-08-12 2016-05-24 Amazon Technologies, Inc. Fast-booting application image using variation points in application source code
US10346148B2 (en) 2013-08-12 2019-07-09 Amazon Technologies, Inc. Per request computer system instances
US9705755B1 (en) 2013-08-14 2017-07-11 Amazon Technologies, Inc. Application definition deployment with request filters employing base groups
US20150195234A1 (en) * 2014-01-08 2015-07-09 International Business Machines Corporation Preventing unnecessary messages from being sent and received
FI20145150L (en) * 2014-02-14 2015-08-15 Streamr Oy Signal processing system
US9678787B2 (en) 2014-05-23 2017-06-13 Microsoft Technology Licensing, Llc Framework for authoring data loaders and data savers
JP6319459B2 (en) * 2014-11-06 2018-05-09 株式会社島津製作所 ANALYZER SYSTEM AND PROGRAM FOR THE SYSTEM
US9459933B1 (en) 2015-01-30 2016-10-04 Amazon Technologies, Inc. Contention and selection of controlling work coordinator in a distributed computing environment
CN106375102B (en) * 2015-07-22 2019-08-27 华为技术有限公司 A kind of service registration method, application method and relevant apparatus
US10536518B1 (en) * 2015-11-20 2020-01-14 VCE IP Holding Company LLC Resource configuration discovery and replication system for applications deployed in a distributed computing environment
CA3023279A1 (en) * 2016-05-06 2017-11-09 Schlumberger Canada Limited Seismic processing task predictive scheduler
US10498625B1 (en) * 2016-10-14 2019-12-03 Amazon Technologies, Inc. Distributed testing service
CN108156188B (en) * 2016-12-02 2021-06-01 中科星图股份有限公司 Data validity checking system
US10264056B2 (en) * 2016-12-08 2019-04-16 Bank Of America Corporation Multicomputer processing of an event request from an event origination device with centralized event orchestration
US10417228B2 (en) * 2016-12-16 2019-09-17 General Electric Company Apparatus and method for analytical optimization through computational pushdown
WO2018150503A1 (en) * 2017-02-16 2018-08-23 株式会社日立製作所 Data processing method, distributed data processing system, and storage medium
US11327811B2 (en) * 2017-07-06 2022-05-10 Centurylink Intellectual Property Llc Distributed computing mesh
US10997538B1 (en) 2017-11-21 2021-05-04 Amazon Technologies, Inc. Resource management
US11616686B1 (en) * 2017-11-21 2023-03-28 Amazon Technologies, Inc. Cluster management
WO2019110609A1 (en) * 2017-12-05 2019-06-13 Koninklijke Philips N.V. Multiparty computations
CN109800078B (en) * 2018-12-12 2020-04-28 北京三快在线科技有限公司 Task processing method, task distribution terminal and task execution terminal
US11907755B2 (en) * 2019-11-22 2024-02-20 Rohde & Schwarz Gmbh & Co. Kg System and method for distributed execution of a sequence processing chain
KR102248978B1 (en) * 2019-11-29 2021-05-07 한국과학기술원 Resource Allocation Method and Apparatus for Reducing the Expected Latency in Distributed Machine Learning with Multiple Users
AU2022339498A1 (en) 2021-08-31 2024-03-14 Nutcracker Therapeutics, Inc. State machine based script applications and systems

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6397173B1 (en) * 1999-05-03 2002-05-28 Astec International Llc Application specific waveform generator
US20020091752A1 (en) * 2001-01-09 2002-07-11 Firlie Bradley M. Distributed computing
US6895338B2 (en) * 2000-03-10 2005-05-17 Smiths Detection - Pasadena, Inc. Measuring and analyzing multi-dimensional sensory information for identification purposes
US20050289274A1 (en) * 2004-06-23 2005-12-29 National Instruments Corporation Compact modular embedded device
US20060053211A1 (en) * 2004-07-16 2006-03-09 Jacob Kornerup Deterministic communication between graphical programs executing on different computer systems
US7093004B2 (en) * 2002-02-04 2006-08-15 Datasynapse, Inc. Using execution statistics to select tasks for redundant assignment in a distributed computing platform
US7254607B2 (en) * 2000-03-30 2007-08-07 United Devices, Inc. Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US7305475B2 (en) * 1999-10-12 2007-12-04 Webmd Health System and method for enabling a client application to operate offline from a server
US7490029B2 (en) * 2000-06-19 2009-02-10 P.C. Krause & Associates, Inc. Distributed simulation

Family Cites Families (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4890242A (en) * 1986-06-05 1989-12-26 Xox Corporation Solid-modeling system using topology directed subdivision for determination of surface intersections
US5481698A (en) * 1988-09-28 1996-01-02 Hitachi Ltd. Computer system and job executing method
JPH07120410B2 (en) * 1991-01-15 1995-12-20 インターナショナル・ビジネス・マシーンズ・コーポレイション Large-scale parallel architecture display / manipulation system and method for three-dimensional object
JPH05197573A (en) * 1991-08-26 1993-08-06 Hewlett Packard Co <Hp> Task controlling system with task oriented paradigm
US5420965A (en) * 1992-06-05 1995-05-30 Software Projects, Inc. Single pass method of compressing data transmitted to command driven terminal
US5390325A (en) * 1992-12-23 1995-02-14 Taligent, Inc. Automated testing system
SE9300671D0 (en) * 1993-03-01 1993-03-01 Sven Nauckhoff WORK FLOW MANAGEMENT
US5490097A (en) * 1993-03-22 1996-02-06 Fujitsu Limited System and method for modeling, analyzing and executing work process plans
AU679637B2 (en) * 1994-04-21 1997-07-03 British Telecommunications Public Limited Company Interface device and method
US5526358A (en) * 1994-08-19 1996-06-11 Peerlogic, Inc. Node management in scalable distributed computing enviroment
US5748930A (en) * 1994-09-26 1998-05-05 Intel Corporation Method and apparatus for interfacing with a host computer system sharing tasks with another user on a client computer system
US5940586A (en) * 1995-10-16 1999-08-17 International Business Machines Corporation Method and apparatus for detecting the presence of and disabling defective bus expansion devices or Industry Standard Architecture (ISA) adapters
US5784884A (en) * 1995-12-20 1998-07-28 United Technologies Corporation Fail-safe transfer valve
US5838968A (en) * 1996-03-01 1998-11-17 Chromatic Research, Inc. System and method for dynamic resource management across tasks in real-time operating systems
US5761507A (en) * 1996-03-05 1998-06-02 International Business Machines Corporation Client/server architecture supporting concurrent servers within a server with a transaction manager providing server/connection decoupling
US5930465A (en) * 1996-11-26 1999-07-27 Xerox Corporation Printing system with enhanced print service capability
US5950201A (en) * 1996-12-06 1999-09-07 International Business Machines Corporation Computerized design automation method using a single logical PFVL paradigm
US5905657A (en) * 1996-12-19 1999-05-18 Schlumberger Technology Corporation Performing geoscience interpretation with simulated data
US6112243A (en) * 1996-12-30 2000-08-29 Intel Corporation Method and apparatus for allocating tasks to remote networked processors
US5923552A (en) * 1996-12-31 1999-07-13 Buildnet, Inc. Systems and methods for facilitating the exchange of information between separate business entities
US6006230A (en) * 1997-01-15 1999-12-21 Sybase, Inc. Database application development system with improved methods for distributing and executing objects across multiple tiers
US6003065A (en) * 1997-04-24 1999-12-14 Sun Microsystems, Inc. Method and system for distributed processing of applications on host and peripheral devices
US6173322B1 (en) * 1997-06-05 2001-01-09 Silicon Graphics, Inc. Network request distribution based on static rules and dynamic performance data
US6058426A (en) * 1997-07-14 2000-05-02 International Business Machines Corporation System and method for automatically managing computing resources in a distributed computing environment
US5926775A (en) * 1997-10-08 1999-07-20 National Instruments Corporation Mini driver software architecture for a data acquisition system
US6697773B1 (en) * 1998-05-19 2004-02-24 Altera Corporation Using assignment decision diagrams with control nodes for sequential review during behavioral simulation
US6577981B1 (en) * 1998-08-21 2003-06-10 National Instruments Corporation Test executive system and method including process models for improved configurability
US6332211B1 (en) * 1998-12-28 2001-12-18 International Business Machines Corporation System and method for developing test cases using a test object library
US6564326B2 (en) * 1999-07-06 2003-05-13 Walter A. Helbig, Sr. Method and apparatus for enhancing computer system security
US6463457B1 (en) * 1999-08-26 2002-10-08 Parabon Computation, Inc. System and method for the establishment and the utilization of networked idle computational processing power
US6993747B1 (en) * 1999-08-30 2006-01-31 Empirix Inc. Method and system for web based software object testing
US7139999B2 (en) * 1999-08-31 2006-11-21 Accenture Llp Development architecture framework
US7260635B2 (en) * 2000-03-21 2007-08-21 Centrisoft Corporation Software, systems and methods for managing a distributed network
US20030154284A1 (en) * 2000-05-31 2003-08-14 James Bernardin Distributed data propagator
AU2001266948A1 (en) * 2000-06-14 2001-12-24 Douglas M. Blair Apparatus and method for providing sequence database comparison
US20020019844A1 (en) * 2000-07-06 2002-02-14 Kurowski Scott J. Method and system for network-distributed computing
IL137296A (en) * 2000-07-13 2009-09-01 Nds Ltd Configurable hardware system
WO2002023463A1 (en) * 2000-09-11 2002-03-21 David Edgar System, method, and computer program product for optimization and acceleration of data transport and processing
US6950874B2 (en) * 2000-12-15 2005-09-27 International Business Machines Corporation Method and system for management of resource leases in an application framework system
US20020161890A1 (en) * 2000-12-22 2002-10-31 Kailai Chen System and method for intelligently distributing content over a communicatons network
US20020087382A1 (en) * 2001-01-03 2002-07-04 Tiburcio Vincio B. Method and system for assigning and tracking tasks, such as under an electronic auction
US20020186384A1 (en) * 2001-06-08 2002-12-12 Winston Edward G. Splitting a print job for improving print speed
US7222265B1 (en) * 2001-07-02 2007-05-22 Lesuer Brian J Automated software testing
US7266808B2 (en) * 2001-08-10 2007-09-04 Parasoft Corporation Method and system for dynamically invoking and/or checking conditions of a computer test program
US20030036866A1 (en) * 2001-08-14 2003-02-20 Dinesh Nair System and method for creating a test executive sequence to perform display inspection
US7020699B2 (en) * 2001-09-11 2006-03-28 Sun Microsystems, Inc. Test result analyzer in a distributed processing framework system and methods for implementing the same
US6993772B2 (en) * 2001-09-18 2006-01-31 The Mathworks, Inc. Common communication system for control instruments
US6910158B2 (en) * 2001-10-01 2005-06-21 International Business Machines Corporation Test tool and methods for facilitating testing of duplexed computer functions
US7721193B2 (en) * 2001-10-18 2010-05-18 Bea Systems, Inc. System and method for implementing a schema object model in application integration
US7275048B2 (en) * 2001-10-30 2007-09-25 International Business Machines Corporation Product support of computer-related products using intelligent agents
WO2003038648A2 (en) * 2001-10-31 2003-05-08 Thermo Crs Ltd. A backtracking resources planning algorithm
US7117500B2 (en) * 2001-12-20 2006-10-03 Cadence Design Systems, Inc. Mechanism for managing execution of interdependent aggregated processes
US20030131088A1 (en) * 2002-01-10 2003-07-10 Ibm Corporation Method and system for automatic selection of a test system in a network environment
US7130891B2 (en) * 2002-02-04 2006-10-31 Datasynapse, Inc. Score-based scheduling of service requests in a grid services computing platform
US7376693B2 (en) * 2002-02-08 2008-05-20 Jp Morgan Chase & Company System architecture for distributed computing and method of using the system
WO2003088119A1 (en) * 2002-04-08 2003-10-23 Topcoder, Inc. System and method for soliciting proposals for software development services
US20040044909A1 (en) * 2002-09-04 2004-03-04 Mirza Absar Ahmed Method and system for accessing an object behind a firewall
US20040047356A1 (en) * 2002-09-06 2004-03-11 Bauer Blaine D. Network traffic monitoring
US7334219B2 (en) * 2002-09-30 2008-02-19 Ensco, Inc. Method and system for object level software testing
US7395536B2 (en) * 2002-11-14 2008-07-01 Sun Microsystems, Inc. System and method for submitting and performing computational tasks in a distributed heterogeneous networked environment
US7421683B2 (en) * 2003-01-28 2008-09-02 Newmerix Corp£ Method for the use of information in an auxiliary data system in relation to automated testing of graphical user interface based applications
US7209851B2 (en) * 2003-02-14 2007-04-24 Advantest America R&D Center, Inc. Method and structure to develop a test program for semiconductor integrated circuits
US20040167749A1 (en) * 2003-02-21 2004-08-26 Richard Friedman Interface and method for testing a website
US20040210866A1 (en) * 2003-04-17 2004-10-21 Richard Friedman Method of creating a unit test framework to test a resource description framework based object
US20050027846A1 (en) * 2003-04-24 2005-02-03 Alex Wolfe Automated electronic software distribution and management method and system
US7644408B2 (en) * 2003-04-25 2010-01-05 Spotware Technologies, Inc. System for assigning and monitoring grid jobs on a computing grid
US8055753B2 (en) * 2003-06-11 2011-11-08 International Business Machines Corporation Peer to peer job monitoring and control in grid computing systems
US6882951B2 (en) * 2003-07-07 2005-04-19 Dell Products L.P. Method and system for information handling system automated and distributed test
US20050034130A1 (en) * 2003-08-05 2005-02-10 International Business Machines Corporation Balancing workload of a grid computing environment
US7330281B2 (en) * 2003-08-25 2008-02-12 Sharp Laboratories Of America, Inc. Systems and methods for providing imaging job control
EP1673607A4 (en) * 2003-10-14 2009-05-20 Verseon Method and apparatus for analysis of molecular configurations and combinations
JP5032120B2 (en) * 2003-10-14 2012-09-26 バーセオン Method and apparatus for classifying molecules
EP1680741B1 (en) * 2003-11-04 2012-09-05 Kimberly-Clark Worldwide, Inc. Testing tool for complex component based software systems
US20060048157A1 (en) * 2004-05-18 2006-03-02 International Business Machines Corporation Dynamic grid job distribution from any resource within a grid environment
US7844969B2 (en) * 2004-06-17 2010-11-30 Platform Computing Corporation Goal-oriented predictive scheduling in a grid environment
US7886296B2 (en) * 2004-07-22 2011-02-08 Computer Associates Think, Inc. System and method for providing alerts for heterogeneous jobs

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6397173B1 (en) * 1999-05-03 2002-05-28 Astec International Llc Application specific waveform generator
US7305475B2 (en) * 1999-10-12 2007-12-04 Webmd Health System and method for enabling a client application to operate offline from a server
US6895338B2 (en) * 2000-03-10 2005-05-17 Smiths Detection - Pasadena, Inc. Measuring and analyzing multi-dimensional sensory information for identification purposes
US7254607B2 (en) * 2000-03-30 2007-08-07 United Devices, Inc. Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US7490029B2 (en) * 2000-06-19 2009-02-10 P.C. Krause & Associates, Inc. Distributed simulation
US20020091752A1 (en) * 2001-01-09 2002-07-11 Firlie Bradley M. Distributed computing
US7093004B2 (en) * 2002-02-04 2006-08-15 Datasynapse, Inc. Using execution statistics to select tasks for redundant assignment in a distributed computing platform
US20050289274A1 (en) * 2004-06-23 2005-12-29 National Instruments Corporation Compact modular embedded device
US20060053211A1 (en) * 2004-07-16 2006-03-09 Jacob Kornerup Deterministic communication between graphical programs executing on different computer systems

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9552488B2 (en) * 2010-12-20 2017-01-24 Konica Minolta Business Technologies, Inc. Image forming apparatus
US20120154849A1 (en) * 2010-12-20 2012-06-21 Konica Minolta Business Technologies, Inc. Image forming apparatus
US10394792B1 (en) 2011-04-20 2019-08-27 Google Llc Data storage in a graph processing system
US9104665B1 (en) * 2011-04-20 2015-08-11 Google Inc. Data backup in a graph processing system
US10268777B2 (en) * 2011-04-20 2019-04-23 Google Llc Data backup in a graph processing system
US9495477B1 (en) 2011-04-20 2016-11-15 Google Inc. Data storage in a graph processing system
US11036603B1 (en) * 2011-07-15 2021-06-15 Scale Computing Inc Distributed test suite tools
US9269063B2 (en) 2011-09-23 2016-02-23 Elwha Llc Acquiring and transmitting event related tasks and subtasks to interface devices
US9710768B2 (en) 2011-09-23 2017-07-18 Elwha Llc Acquiring and transmitting event related tasks and subtasks to interface devices
US20140351362A1 (en) * 2011-11-02 2014-11-27 Hitachi, Ltd. Computer system, data transfer method, and data transfer program
US20130117751A1 (en) * 2011-11-09 2013-05-09 Jerome F. Duluk, Jr. Compute task state encapsulation
US10795722B2 (en) * 2011-11-09 2020-10-06 Nvidia Corporation Compute task state encapsulation
US8910186B2 (en) * 2011-11-15 2014-12-09 International Business Machines Corporation Feed-based promotion of service registry objects
US20130263090A1 (en) * 2012-03-30 2013-10-03 Sony Online Entertainment Llc System and method for automated testing
US20130268937A1 (en) * 2012-04-09 2013-10-10 Samsung Electronics Co., Ltd. Distributed processing system, scheduler node and scheduling method of distributed processing system, and program generation apparatus thereof
US9965322B2 (en) * 2012-04-09 2018-05-08 Samsung Electronics Co., Ltd. Scheduling tasks in a distributed processing system with both reconfigurable and configurable processors
US9117029B2 (en) * 2012-12-05 2015-08-25 The Mathworks, Inc. Deferred evaluation and presentation of a custom diagnostic analysis
US20140157242A1 (en) * 2012-12-05 2014-06-05 The Mathworks, Inc. Deferred evaluation and presentation of a custom diagnostic analysis
US9858137B2 (en) 2013-12-04 2018-01-02 Exfo Inc. Network test system
US9921633B2 (en) 2014-08-22 2018-03-20 Intel Corporation Power aware job scheduler and manager for a data processing system
US10289183B2 (en) 2014-08-22 2019-05-14 Intel Corporation Methods and apparatus to manage jobs that can and cannot be suspended when there is a change in power allocation to a distributed computer system
US9927857B2 (en) * 2014-08-22 2018-03-27 Intel Corporation Profiling a job power and energy consumption for a data processing system
US10712796B2 (en) 2014-08-22 2020-07-14 Intel Corporation Method and apparatus to generate and use power, thermal and performance characteristics of nodes to improve energy efficiency and reducing wait time for jobs in the queue
US9575536B2 (en) 2014-08-22 2017-02-21 Intel Corporation Methods and apparatus to estimate power performance of a job that runs on multiple nodes of a distributed computer system
US20160054774A1 (en) * 2014-08-22 2016-02-25 Intel Corporation Profiling a job power and energy consumption for a data processing system
CN116860487A (en) * 2023-09-04 2023-10-10 南京国睿信维软件有限公司 Matlab integrated scheduling method based on RMI technology

Also Published As

Publication number Publication date
JP5442999B2 (en) 2014-03-19
US20080021951A1 (en) 2008-01-24
US20070124363A1 (en) 2007-05-31
WO2007070491A3 (en) 2007-10-04
EP1960877A2 (en) 2008-08-27
WO2007070491A2 (en) 2007-06-21
JP2009519548A (en) 2009-05-14
US7908313B2 (en) 2011-03-15

Similar Documents

Publication Publication Date Title
US7908313B2 (en) Instrument-based distributed computing systems
US7454659B1 (en) Distributed systems in test environments
US9507634B1 (en) Methods and system for distributing technical computing tasks to technical computing workers
US8612980B2 (en) Distribution of job in a portable format in distributed computing environments
US8230424B2 (en) General interface with arbitrary job managers
US8732685B2 (en) Methods and system for executing a program in multiple execution environments
US9582330B2 (en) Methods and system for distributing data to technical computing workers
US8056079B1 (en) Adding tasks to queued or running dynamic jobs
US7730166B2 (en) Dynamic definition for concurrent computing environments
US7631168B1 (en) Graphical interface for grouping concurrent computing units executing a concurrent computing process
US20090031066A1 (en) Capacity planning by transaction type
Lin et al. ABS-YARN: A formal framework for modeling Hadoop YARN clusters
US8863130B2 (en) Exception handling in a concurrent computing process
US9405564B2 (en) System and method for targeting commands to concurrent computing units executing a concurrent computing process
US7502745B1 (en) Interfaces to a job manager in distributed computing environments
US8095937B1 (en) Methods and apparatus providing payload event processing for managed objects

Legal Events

Date Code Title Description
AS Assignment

Owner name: THE MATHWORKS, INC., MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LURIE, ROY;GAUDETTE, THOMAS;REEL/FRAME:026045/0993

Effective date: 20060307

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION