CN106537343A - Systems and methods for parallel processing using dynamically configurable active co-processing units - Google Patents

Abstract

A parallel processing architecture comprising: a CPU, a task pool populated via the CPU, and a plurality of autonomous co-processing units, each having an agent configured to actively interrogate the task pool to retrieve tasks appropriate for a particular co-processor. Each co-processor communicates with the task pool through a switch fabric, which facilitates the connection of data transfer and arbitration between all system resources. Each co-processor notifies the task pool when a task or task thread is completed, and thus the task pool notifies the CPU.

Description

Systems and methods for parallel processing using dynamically configurable active co-processing units

This application is a continuation of US Application Serial No. 13/750,696, filed January 25, 2013, which is incorporated herein by reference.

technical field

The present invention relates generally to parallel processing computing, and more particularly to a processing architecture involving active co-processors configured to actively retrieve tasks from a task pool populated via a central processing unit.

Background technique

The Internet of Things (also known as IoT Cloud) refers to an ad hoc network of uniquely identifiable embedded computing devices within existing Internet infrastructure. The Internet of Things (IoT) means advanced connectivity of devices, systems and services beyond machine-to-machine communication (M2M). The range of things envisioned by the IoT is limitless and could include applications such as heart monitoring implants, biochip transponders, automotive sensors, aerospace and defense field operations equipment, and public safety applications such as assisting firefighters in search and rescue operations device of. Current market examples include home-based networking involving smart thermostats, light bulbs, and washer/dryers utilizing wifi for remote monitoring. Due to the ubiquitous nature of connected objects in IoT, it is estimated that by 2020, more than 30 billion devices will be wirelessly connected to IoT. It is an object of the present invention to utilize the processing power of the controllers and processors associated with these devices.

Computer processors typically execute machine-coded instructions serially. To run multiple applications simultaneously, a single processor interleaves instructions from the various programs and executes them serially, even though from the user's perspective the applications appear to be processed in parallel. On the other hand, true parallel processing, or multi-core processing, is a method of computing that divides large computing tasks into separate computing blocks and distributes them among two or more computers. Computing architectures that use task parallelism (parallel processing) divide large computing needs into discrete modules of executable code. These modules are then executed concurrently or sequentially based on their respective priorities.

A typical multiprocessor system includes a central processing unit (CPU) and one or more coprocessors. The CPU divides computing needs into tasks and distributes these tasks to co-processors. Completed threads are reported to the CPU, which continues to dispatch additional threads to coprocessors as needed. Disadvantages of currently known multiprocessing methods are: task dispatch consumes a lot of CPU bandwidth; wait for tasks to complete before dispatching new ones (often with dependencies on previous tasks); respond to interrupts from coprocessors when tasks complete ;Respond to other messages from the coprocessor. Additionally, coprocessors typically remain idle while waiting for new tasks from the CPU.

Therefore, there is a need for a multiprocessor architecture that reduces CPU management overhead and also more efficiently processes and utilizes available co-processing resources.

Contents of the invention

Various embodiments of a parallel processing computing architecture include: a CPU configured to populate a task pool; and one or more co-processors configured to actively retrieve threads (tasks) from the task pool. Each co-processor notifies the task pool when a task is complete and pings back to the task pool until another task becomes available for processing. In this way, the CPU communicates directly with the task pool and indirectly with the co-processors through the task pool.

Co-processors may also be capable of operating autonomously; that is, they may interact with the task pool independently of the CPU. In a preferred embodiment, each co-processor includes an agent that queries the task pool to search for tasks to execute. Thus, the co-processors work together "equivalently" with each other and with the task pool to fulfill cluster computing needs by automatically retrieving and completing independent tasks that may or may not be interrelated. As a non-limiting example, assume task B involves calculating the average temperature over time. By defining Task A to include capturing temperature degrees over time, and further defining Task B to include taking captured readings, the CPU and various co-processors can thus communicate with each other via the task pool.

In various embodiments, co-processors are referred to as automatic, active equivalent units. In this context, the term "autonomous" means that the coprocessor can interact with the task pool without being instructed to do so by the CPU or the task pool. The term "active" proposes that each coprocessor may be configured (eg, programmed) to periodically send agents to monitor available tasks in the task pool suitable for that coprocessor. The term "equal" means that the co-processing units share a common goal in monitoring and executing all available tasks in the task pool.

The equivalent unit (co-processor) may be a general purpose processor or a special purpose processor and thus may have the same or a different instruction set, architecture and microarchitecture than the CPU or other equivalent units in the system. Also, software programs to be executed and data to be processed may be included in one or more storage units. In a conventional computer system, for example, a software program includes a string of instructions that may require data to be used by the program. For example, if the program corresponds to a media player, the data contained in the memory may be compressed audio data that can be read by the co-processor and eventually played on speakers.

Each equivalent unit in the system can be configured to communicate resistively or wirelessly with the task pool through a crossbar switch (also called a fabric). In a pure wireless mesh topology, the radio signals themselves form the structure. In various embodiments, co-processors may also communicate directly with the CPU. The switching structure facilitates communication between system resources. Each peer unit is active in that it obtains processing by sending its agents to the task pool when the peer unit has no processing to perform, or when the peer unit is able to contribute to the processing cycle without hindering its normal operation. task. As a non-limiting example, in the context of the Internet of Things (discussed in more detail below), a co-processor associated with a device such as a light bulb could be programmed to listen for "on" and The "off" command acts as its normal operation, but its processing resources can also be utilized through the task pool.

In the context of the various embodiments described herein, the term "agent" refers to a software module, similar to a network package, associated with a coprocessor that interacts with a pool of tasks to obtain access to a coprocessor. Available tasks for which the processor unit is suitable. Peer units may execute tasks sequentially when a task may be in the run of a previous task, or in parallel when more than one peer unit is available and more than one matching task is available for execution. Depending on the task thread limit (if any) provided by the CPU, tasks may be executed independently or cooperatively. Tasks that depend on each other in a task pool can be logically combined. The task pool notifies the CPU when a task thread has completed. If a task thread includes a single task, the task pool can notify the CPU when the task is complete. If a task thread includes multiple tasks, the task pool notifies the CPU when such a chain of tasks is completed. Since task threads can be logically combined, it is conceivable to have a case where the task pool notifies the CPU after the logically combined task threads are completed.

Those skilled in the art will appreciate that interoperation between a CPU and coprocessors can be facilitated by configuring the CPU to combine and/or structure tasks at a level of abstraction independent of the instruction set architecture associated with the various coprocessors nature, allowing components to communicate at the task level rather than at the instruction level. Thus, devices and their associated co-processors can be added to the network on a "plug and play" basis. Another aspect of the invention provides interoperability within a heterogeneous array of CPUs with different instruction set architectures.

The various features of the invention are particularly applicable to networks of IoT devices and sensors; heterogeneous computing environments; high performance computing, 2D and 3D monolithic integrated circuits; motion control and robotics.

Description of drawings

The present invention will hereinafter be described with reference to the accompanying drawings, wherein like numerals represent similar elements, in the accompanying drawings:

1 is a schematic block diagram of a parallel processing architecture including a CPU, a memory, a task pool, and a plurality of coprocessors configured to communicate via a fabric, according to an embodiment;

Figure 2 is a schematic block diagram illustrating details of an exemplary task pool according to an embodiment;

Figure 3 is a schematic block diagram of a network comprising collaborative processing units and their corresponding agents interacting with task pools, according to an embodiment;

Figure 4 is a schematic layout of the Internet of Things including available plugs and playback devices according to an embodiment;

Figure 5 is a schematic layout of an exemplary Internet of Things use case illustrating dynamic handling of nearby devices according to an embodiment;

Figure 6 is a flowchart illustrating the operation of an exemplary parallel computing environment according to an embodiment.

detailed description

Various embodiments relate to parallel processing computing systems and environments, ranging from simple switching and control functions to complex programs and algorithms, including but not limited to: data encryption; graphics, video, and audio processing; direct memory access; mathematical computing; data mining ; game algorithms; Ethernet packets and other network protocol processing, including data construction, reception and transmission of external networks; financial services and business methods; search engines; Internet data streaming and other network-based applications; execution of internal or external software programs; For example, switching on and off and/or otherwise controlling or manipulating appliances, light bulbs, consumer electronics, etc. in the context of the Internet of Things.

The various features may be incorporated into any currently known or later developed computer architecture. For example, parallel processing problems involving synchronization, data safety, out-of-order execution, and host processor interrupts can be solved using the inventive concepts described herein.

Referring now to FIG. 1 , a distributed processing system 10 includes a single-core or multi-core CPU 11 and one or more equivalent or co-processing units 12A-12 configured to communicate with a task pool 13 via a crossbar switch structure 14 . The equivalent units 12 may also communicate with each other via the switch fabric 14 or via a separate unit bus (not shown). CPU 11 may communicate with task pool 13 directly or via switch fabric 14 . Each of the one or more storage units 15 contains data and/or instructions. In this context, the term “instructions” includes compiled software programs executable via the CPU 11 . Storage unit 15 , unit 12 and task pool 13 may be resistively or wirelessly interconnected to communicate with the CPU and/or each other via switching fabric 14 . In some embodiments, CPU 11 communicates with unit 12 only indirectly through a task pool. In other embodiments, the CPU 11 can also directly communicate with the unit 12 without using a task pool as an intermediary.

In some embodiments, the system 10 may include more than one CPU 11 and more than one task pool 13, in which case a specific CPU 11 may interact with a specific task pool 13, or multiple CPUs 11 can share one or more task pools 13 . Furthermore, each peer unit may be configured to interact with more than one task pool 13 . Optionally, a particular unit can be configured to interact with a single designated task pool, for example, in high-performance or high-security environments.

In various embodiments, a unit can be dynamically paired with a task pool, resistively (plug and play) or wirelessly (over the air), when the following three conditions are met:

1) The unit is capable of resistive or wireless communication with the task pool. The connection to the task pool can be through a port in the task pool itself, or through a switch structure connected to the task pool;

2) The task pool identifies that the agent sent by the unit is authentic, e.g. using input from the user with or without a passcode, via traditional Wi-Fi, Bluetooth or similar pairing, manually via a smartphone or tablet run graphics software programs or through any other secure or unsecure method;

3) At least one available task in the task pool is compatible with the capabilities of the equivalent unit.

In the case of a multiprocessor environment with multiple task pools, the aforementioned dynamic pairing conditions apply, except that a given unit may be locked or restricted to work only with either task pool; otherwise, the unit may use the first lookup Basis, cyclic basis, or any other selection scheme, connected to one or more task pools. Tasks in the task pool may also be assigned priorities whereby the unit gives priority to high priority tasks and services lower priority tasks when not otherwise occupied by higher priority tasks.

The CPU 11 may be a single-core or multi-core processor, an application processor, or a microcontroller for executing software programs. System 10 may be implemented on a personal computer, smart phone, tablet, internet appliance, in which case CPU 11 may be any personal computer, central processing unit or cluster of processors, such as, Or local or remote multi-core processors for immediate computing environments. Alternatively, system 10 may be implemented on a supercomputer, and CPU 11 may be a Reduced Instruction Set Computer ("RISC") processor, an application processor, a microprocessor, or the like.

In other embodiments, system 10 may be implemented on a series of locally connected personal computers (such as a Beowulf cluster), in which case CPU 11 may include all central processing units, a subset, or One of the networked computers. Alternatively, system 10 may be implemented over a network of remotely connected computers, in which case CPU 11 may be a central processing unit for servers or mainframes now known or later developed. The specific manner in which the CPU 11 executes the object parallel processing method within the presently described system 10 may be affected by the operating system of the CPU. For example, as described below, CPU 11 may be configured for use within system 10 by programming it to recognize and communicate with task pool 13 and divide computing requirements into threads.

It is also contemplated that system 10 may be implemented retroactively on any computer or network of computers having an operating system that may be modified or otherwise configured to carry out the functions described herein. As is known in the art, the data to be processed is contained within a memory unit 15, such as a cache memory for the CPU 11 in the context of random-access addressable areas or partitions or read-only memory, or other Forms of data storage such as flash memory and magnetic storage. The memory unit 15 contains the data to be processed and the location where the results of the processed data are placed. Not every task requires access to the memory unit 15, eg in the case of smart and automotive meters, which may return data to the system 10, or in the case of robotics and motor controllers, which may brake the machine.

Each unit 12 is conceptually or logically an independent computing unit capable of running one or more tasks/threads. Unit 12 may be a microcontroller, microprocessor, application processor, "dumb" switch, or a stand-alone computer, such as a machine in a Beowulf cluster.

Unit 12 may be a general-purpose or special-purpose co-processor configured to supplement, perform all or a limited range of functions of the CPU, or functions external to CPU 11 such as environmental monitoring and robotic actuators, for example. A special-purpose processor can be a special-purpose hardware module designed, programmed, or otherwise configured to perform specialized tasks, or it can be a general-purpose processor configured to perform specialized tasks such as graphics processing, floating-point arithmetic, or data encryption.

In an embodiment, any unit 12 that is a dedicated processor may also be configured to access and write memory and execute descriptors and other software programs as described below.

Furthermore, any number of units 12 may comprise a heterogeneous computing environment; that is, a system using more than one type of processor (such as AMD-based and/or Intel-based processors) or a mix of 32-bit and 64-bit processors.

As shown in the following sequence of events, each unit 12 is configured to perform one or more dedicated tasks. During the polling phase, each unit periodically sends agents to the task pool until a matching task is found. To facilitate this matching, cells and task pools can be equipped with transceivers. In the case of task pools, the transceiver may be located in the task pool itself or in a switching fabric connected to the task pool. When a task match is found within the task pool, the task pool sends an acknowledgment to the unit. The next step is the "communication channel" phase. In the communication channel phase, the unit receives the task and starts executing the task. In one embodiment, once the first task is completed, the communication signal is maintained so that the equivalent unit can grab other tasks without repeating the "poll" and "acknowledgement" phases.

System 10 may include multiple units, where some of these units are capable of performing the same type of tasks as other units, thereby creating redundancy in system 10 . The set of task types performed by a given unit 12 may be a subset of the set of task types performed by another unit. For example, in FIG. 1 , system 10 may divide aggregated computing problems into task groups, populating task pool 13 with tasks of a first type, a second type, and a third type. The first unit 12A may be capable of performing only a first type of task; the second unit 12B may be capable of performing a second type of task; the third unit 12C may be capable of performing a third type of task; the fourth unit 12D may be capable of performing a second or second type of task. A third type of task; the fifth unit 12N may be capable of performing all three task types. System 10 can be configured with such redundancy so that if a given unit is removed from system 10 (or is currently busy or otherwise unavailable), system 10 can continue to operate seamlessly. Furthermore, if units are dynamically added to the system 10, the system 10 can continue to operate seamlessly with the benefit of higher performance.

Referring now to FIGS. 1 and 2 , task pool 13 may occupy an area of physical memory accessible by CPU 11 . Optionally, the task pool 13 can be accessed by MAC address or IP address. Multiple embodiments are envisioned for the task pool 13; it may be physically located in the same 2D or 3D monolithic IC as the CPU, or it may be implemented as a separate IC and physically interconnected to a computer board, smartphone, tablet Computers, routers or IoT devices. In another alternative embodiment, the task pool may be an independent multi-port, wired and/or wirelessly connected device that may be shared between multiple CPU 11 systems or dedicated to a given CPU 11 . Task pool 13 is also addressable by unit 12 . The task pool 13 can be arranged in a dedicated hardware block to provide maximum access speed by the CPU 11 and unit 12 . Alternatively, the task pool 13 may be software-based, wherein, similar to the hardware-based embodiment, the content of the task pool 13 is stored in memory, but represented by a data structure.

When populated by CPUs 11 , task pool 13 contains one or more task threads 21 . Each task thread 21 represents a computing task, which may be a component or subset of a larger aggregate computing demand placed on CPU 11 . In one embodiment, CPU 11 may initialize and then populate task pool 13 with concurrently executable threads 21 . Each thread 21 may include one or more discrete tasks 22 . A task 22 may have a task type and a descriptor. The task type indicates which units 12 are capable of performing the task 22 . The task pool 13 may also use task types to prioritize tasks 22 of the same type. In one embodiment, task pool 13 may maintain a priority table (not shown) that records the equivalent units 12 that exist in system 10, the types of tasks 22 that each unit is capable of performing, and whether each unit is currently processing. As described below, task pool 13 may use a priority table to determine which eligible tasks 22 to assign to requesting units.

In some embodiments, CPU 11 may retrieve and execute tasks or threads from a task pool. Additionally, CPU 11 may interrupt any task that is determined to be obsolete, corrupt, stuck, or erroneous. In this case, the CPU 11 can update the task to make it available for subsequent processing. Nothing prevents the CPU 11 from implementing adaptive task management, eg, as artificial intelligence may require, whereby the CPU 11 can add, remove or change outstanding tasks within existing threads 21 .

A descriptor may contain one or more of the specific instruction to be executed, the mode of execution, the location (eg, address) of data to be processed, and the placement location (if any) of the task result. The placement of the results is optional, such as in the case of animation and multimedia tasks, which typically present the results to a display rather than storing them in memory. Furthermore, task descriptors can be linked together, such as in a linked list, so that fewer memory calls can be used to access the data to be processed than if the descriptors were not linked together. In one embodiment, the descriptor is a data structure containing a header and a number of reference pointers to memory locations, and task 22 includes the memory address of the data structure. The header defines the functions or instructions to be executed. The first pointer refers to the location of the data to be processed. The second optional pointer references where to place the processing data. If the descriptor is linked to another descriptor to be executed sequentially, the descriptor may include a third pointer referencing the next descriptor. In an alternate embodiment where the descriptor is a data structure, task 22 may include the complete data structure.

Threads 21 may also include "recipes" that describe the order in which tasks 22 may be executed and any conditions that affect the order of performance. Depending on the recipe, tasks 22 may be executed sequentially, simultaneously, out of order, interdependently, or conditionally according to Boolean operations. For example, as shown in FIG. 2, thread 21A includes four tasks: 22A, 22B, 22C, and 22D. In the illustrated embodiment, the first task 22A must complete before either the second task 22B or the third task 22C can begin. According to the recipe, once either the second task 22B or the third task 22C is completed, the fourth task 22D may begin.

Threads 21 may also be interdependent. For example, as shown in FIG. 2 , due to a Boolean operation in thread 21B, completed task 22C may allow processing of tasks in thread 21B to continue. The task pool 13 may lock a task 22 while the task 22 is waiting for the completion of another task 22 on which it depends. When a task 22 is locked, it cannot be acquired by a unit. When the task 22 of the thread 21 is completed, the task pool 13 may notify the CPU 11 of the completion. The CPU can then overrun the thread 21 for processing.

These units advantageously remain identical to each other and to the CPU 11 , thereby helping the system 10 to perform complex calculations by autonomously and actively retrieving tasks from the task pool 13 . Units 12 operate autonomously in that they may be independent of CPU 11 or any other co-processor. Optionally, the CPU can act or instruct the unit directly. Each unit acts proactively in that it seeks tasks 22 from the task pool 13 as soon as the unit becomes available for further processing.

More specifically, in one embodiment, a unit 12 acquires tasks from the task pool by sending an agent 30 to query (search) the task pool and retrieve available tasks 22 that need to be completed, are unlocked, and have tasks that the unit can execute Types of. In general, system 10 has the same number of agents as equivalent co-processing units. In this context, proxies are often analogous to data frames in the networking sense, since a proxy can be equipped with a source address, a destination address, and a payload. In an embodiment, the destination address is the address of the task pool 13 when the agent 30 is looking for a task 22 and the address of the corresponding unit 12 when the agent 30 returns to a unit where it has a task 22 . Correspondingly, when the agent 30 is looking for a task 22, the source address is the address of the unit 12, and when the agent 30 returns to the unit where it has a task 22, the source address is the address of the task pool 13.

Additionally, source and destination addresses can facilitate frame synchronization. That is, system 10 may be configured to explicitly distinguish addresses from payload data such that when reading the contents of proxy 30, the destination address indicates the start of a frame and the source address indicates the end of a frame, or vice versa. This allows loads to vary in size when placed between addresses. In another embodiment of a variable-sized payload, proxy 30 may include a header indicating the payload size. The header information can be compared to the payload to verify data integrity. In yet another embodiment, the load may be of fixed length. When an agent 30 is dispatched to the task pool 13 by its co-processor unit, the payload includes identification information of the type of task that the unit 12 can perform. When the agent 30 returns from the task pool 13, the payload includes the descriptors of the tasks 22 in the form of memory locations or global descriptor data structures.

In another embodiment, some or all of the agents 30 are autonomous representatives of their respective corresponding units 12 . That is, each agent 30 may be dispatched by its corresponding unit 12 to retrieve tasks 22 when the unit is idle or able to perform additional processing. In this way, the processing capabilities of the equivalent unit 12 can be more fully utilized, since the unit does not need to sit idle waiting for instructions from the CPU 11 . This approach has the added advantage of reducing CPU overhead by alleviating the need for the CPU to send requests to the unit to retrieve tasks from the task pool. These advantages make system 10 more efficient than conventional computer architectures in which auxiliary modules and co-processors rely on instructions from the main CPU.

Furthermore, the equivalence units 12A to 12n are contradictory to the specific composition of the threads themselves. Instead, the agent is only concerned with finding a match between the capabilities of its corresponding unit and the available tasks 22 to be completed in the task pool 13 . That is, as long as there are available tasks 22 in the task pool 13 and the available tasks 22 match the capabilities of the unit, the system can effectively utilize the processing capability of the unit.

Some or all of the equivalent units 12A to 12n may operate independently of each other, or may communicate with each other to wake up another equivalent unit by switching the fabric 14, through the task pool 13, or upon command or request from the CPU to aid in processing, moving or send data. In one embodiment, agent 30A may search for a match between the task type of ready task 22 and the type of task that unit 12A is capable of executing. The architecture may involve hardcoding the types of tasks the CPU 11 is configured to create. Thus, if the task pool 13 contains three types of tasks 22, and a large computing requirement includes a fourth type of task, this fourth type of task may not be placed in the task pool 13 even though the fourth type of task can be executed. Tasks are included in system 10 or added to system 10 . Accordingly, CPU 11 may be configured to "learn" or be taught how to create a fourth type of task in order to more fully utilize available processing resources.

In another embodiment, agent 30 searches the task 22 descriptor for an executable instruction that matches one of the instructions that unit 12A is capable of executing. When a matching task 22 is found, the agent 30A distributes the descriptor of the matching task 22 to the unit 12A, whereupon the unit 12A starts processing the task 22 . Specifically, agent 30A may distribute the storage address of the descriptor to unit 12A, which retrieves the data structure from memory. Optionally, a complete data structure for the descriptor is included in task 22, which agent 30A may distribute to unit 12A for processing. The descriptor informs the unit 12A which instruction to execute, where in the storage unit 15 the data is to be processed and where in the memory 15 the structure is to be located, can be found. Upon completion of a task 22, the unit 12A notifies the task pool 13 to change the status of the selected task 22 from "to be completed" to "completed". Furthermore, once a unit 12A completes a task 22 , the unit may dispatch its agent 30A to the task pool 13 to search for another task 22 .

Depending on the particular architecture and/or implementation of the system 10, some or all of the agents 30A through 30n may be wired or wireless (e.g., using a Wi-Fi network, wireless Ethernet, wireless USB, wireless bridge, wireless medium repeaters, wireless routers, or Bluetooth pairing) through the system 10. In an embodiment, the agent 30 may be directed wirelessly to the task pool 13 by including a receiver feature on the task pool 13 and further by including a transmitter feature with the unit 12 . Similarly, task pools can wirelessly answer units by equipping the task pool with transmitters and equivalent units with receivers. In this way, the unit can communicate wirelessly with the task pool with or without the use of a switching fabric.

In a preferred embodiment, however, some form of switching structure 14 is utilized. Switching fabric 14 has connections for data transfer and arbitration between system resources. Switching fabric 14 may be a router or a crossbar switch that provides connectivity between the various units and task pools. Switching fabric 14 may also be provided between each equivalent unit 12A to 12n with system resources such as CPU 11, storage unit 15 and conventional system components including, but not limited to, direct memory access units, transmitters, hard drives and their controllers, displays and other I/O devices and other coprocessors). The units 12A through 12n may be physically connected to the switching fabric 14, or the units may be connected wirelessly.

Wireless connection of units to system 10 facilitates dynamic addition and/or removal of units used in system 10 . For example, the CPU 11 can recruit units from other unit systems, allowing dynamic expansion and increased performance. In this way, two or more unit systems (eg, networks) can share equivalent units. In one embodiment, units that become idle may be sought out and/or recruited by another system that requires additional processing resources, ie, that has available processing tasks that need to be completed. Similarly, system 10 may expand performance by incorporating clusters of additional units for specific tasks. For example, system 10 may enhance the performance of encryption/decryption functions, or processing of audio data and/or video data, by incorporating nearby units capable of performing these tasks.

To prevent undesired connections, the CPU 11 may provide the task pool 13 with a list for identifying trusted and/or untrusted units and authentication requirements or protocols or alternatively criteria for identifying trusted and/or untrusted units. Furthermore, the task pool itself may exclude specific units based on low performance, unreliable connections, poor data throughput, or malicious or improper behavior. In various embodiments, units 12 may be added to or excluded from task pool 13 by a user through use of a smartphone, tablet, or other device or application. In one embodiment, the graphical application interface may provide the user with useful static and/or icon information, such as the location of available units and other equipment, performance gains or performance trade-offs as a function of adding or removing specific units from the network. the result of.

In an alternative embodiment, some or all of the co-processing units may be directly connected to the task pool 13, such as by a wired configuration that does not require the switching fabric 14 for communication. Wired connections of units may also facilitate dynamic expansion and contraction of system 10 similar to the wireless configuration described above, although wired connections may be physical (eg, manual) integration and abstraction of peripherals. In either case, the scalability of the system is greatly enhanced compared to conventional parallel processing schemes because co-processors can be added and removed without reprogramming the CPU 11 to account for changes to the system 10 .

Referring now to FIG. 3, a network 300 includes a CPU 302, a first memory 304, a second memory 306, a task pool 308, a switching fabric 310, a first co-processing unit 312 configured to execute (run) type A tasks, configured to A second unit 314 that performs Type B tasks, a third unit 316 that is configured to perform Type C tasks, and a fourth unit 318 that is configured to perform both Type A tasks and Type B tasks. As described above, task pool 308 is populated (eg, by CPU 302 ) by tasks (or task threads) 330 and 332 of task type A; tasks 334 and 336 of task type B; and tasks 340 and 342 of task type C. In an embodiment, each unit preferably has a unique dedicated agent. Specifically, element 312 includes agent 320 ; element 314 includes agent 322 ; element 316 includes agent 324 ; and element 318 includes agent 326 . Each agent preferably includes an information field or a header identifying the type of task that the unit associated with it is configured to perform, eg a single task or a combination of tasks A, B, C.

During operation, when a unit is idle or otherwise has available processing capacity, its agent actively queries the task pool to determine whether any tasks are suitable for that particular unit in the task queue. For example, unit 312 may dispatch its agent 320 to retrieve one or both of tasks 330 and 332 corresponding to task type A. FIG. Similarly, unit 314 may dispatch its agent 322 to retrieve tasks 334 or 336 corresponding to task type B (according to their corresponding priorities), and so on. For units capable of performing more than one task type, such as unit 318 configured to perform task types A and B, agent 326 may retrieve any of tasks 330 , 332 , 334 and/or 336 .

When a task is retrieved from the task pool, the unit can then process the task, typically by retrieving data from a specific location in the first memory 304, processing the data, and storing the processed data at a specific location in the second memory 306 . When the task is completed, the unit notifies the task pool, the task pool marks the task as completed, and the task pool notifies the CPU that the task is completed. Optionally, the task pool can notify the CPU when a task thread has completed, since a task thread can consist of a single task, a string of tasks, or a Boolean combination of tasks. Importantly, retrieval of tasks and processing of data by units can occur without direct communication between the CPU and the individual units.

Referring now to FIG. 4, an Internet of Things network 400 includes a controller (CPU) 402, a task pool 408, and various devices 410 through 422, wherein some or all of the devices include associated or embedded microcontrollers, such as , an integrated circuit (IC) chip or other component that implements processing capabilities. As non-limiting examples, the device may include a light bulb 410, a thermostat 412, an electrical outlet 414, a power switch 416, an appliance (e.g., a toaster) 418, a vehicle 420, a keyboard 422, and virtually anything else capable of interacting with a network, namely Plug and play devices or applications.

In the illustrated embodiment, the controller 402 may be a smartphone, a tablet computer, a laptop, or may include a display 404 and a user interface (e.g., a keyboard) 406 to facilitate user interaction with various devices in the network. interact with other devices. To the extent that the processing power (eg, bandwidth) of the controller 402 may not be sufficient to adequately support the network, the controller may efficiently acquire or recruit processing resources from peripheral devices via a task pool, eg, as explained below in conjunction with FIG. 5 .

Referring now to FIG. 5 , an Internet of Things network 500 use case illustrates the dynamic utilization of nearby (or otherwise available) devices. Network 500 includes a master control unit 502 (eg, a laptop, tablet, or gaming device), a task pool 504 , a first coprocessor device 506 , and a second coprocessor device 508 . An exemplary use case in the context of network 500 will now be described.

Suppose a user is playing a video game on her laptop computer 502 . Video games require detailed computer-generated graphics, and perhaps the processing power in the laptop computer 502 is sufficient to render a single life-like character, but when a second character is introduced onto the screen, the image quality degrades and the character's movement is no longer continuous . The present invention proposes a method of exploiting the processing power of underutilized computer resources located in the vicinity of or available to the user.

To address the need for additional processing power, laptop computer 502 is connected to task pool 504 . In this regard, the laptop itself may be equipped with a task pool, or the task pool may be located as an external device or application within wireless reach from the laptop 502 . In the case of an external task pool, the task pool itself may perform the duties of a switching structure with ports to allow connection to multiple co-processing units. Laptop 502 populates task pool 504 with computationally intensive tasks. Nearby underutilized devices, such as smartphones 508 , then connect to task pool 504 and send their agents to extract matching task types. Thus, smartphone 508 becomes a co-processor that seamlessly assists laptop 502 to enhance the video game experience. The same method can be repeated in case other underutilized processing resources exist and are needed. In fact, even the processing power of available light bulb 506 could be a co-processor for a laptop computer.

6 is a flowchart illustrating the operation of an exemplary parallel computing environment. Specifically, method 600 includes: populating a task pool with tasks (step 602); actively dispatching one or more agents from one or more corresponding units to the task pool (step 604); retrieving and processing the tasks (step 606) ; Notification task pool and CPU task thread has been executed (step 608). The method also includes dynamically incorporating additional devices into the network as needed (step 610).

Accordingly, a processing system is provided that includes a task pool; a controller configured to populate the task pool with a first task; and a first co-processor configured to actively retrieve the first task from the task pool.

In an embodiment, the first co-processor includes a first agent configured to retrieve the first task from the task pool without requiring communication with the controller.

In an embodiment, the first task includes an indicia of a first task type, the first coprocessor is configured to execute the first type of task, and the first agent is configured to search the task pool for the first type of task.

In an embodiment, the first co-processor is further configured to process the first task and notify the task pool when the first task is completed, and the task pool is configured to notify the controller when the first task is completed.

In an embodiment, the controller and the first co-processor are configured to communicate with each other only through the task pool.

In an embodiment, the controller and the first co-processor are configured to communicate with each other both directly and through a task pool.

In an embodiment, the first co-processor is configured to determine that it has available processing capacity and to assign an agent to the task pool in response to said determination.

In an embodiment, the controller is further configured to populate the task pool with a second task, wherein the system further includes a second co-processor configured to actively retrieve the second task from the task pool. Second agent for the task.

In an embodiment, the second task includes an indicia of a second task type, the second coprocessor is configured to execute the second type of task, and the second agent is configured to search the task pool for the second type of task.

In an embodiment, the controller and task pool are resident on a monolithic integrated circuit (IC), and the first coprocessor is not resident on the IC.

In another embodiment, the controller, the task pool, and the first co-processor and the second co-processor reside on a single integrated circuit (IC).

Furthermore, a method of dynamically controlling processing resources in a network comprising a type of central processing unit (CPU) configured to populate a task pool with a first task of a first task type is provided. The method comprises the steps of: programming a first unit to perform a first task type; adding the programmed first unit to the network; actively sending a first agent from the first unit to the task pool; The pool is searched for tasks of the first type; the first agent retrieves the first task from the task pool; the first agent transmits the first task to the first unit; the first unit processes the first task; Sent from the first unit to the task pool.

In an embodiment, the method further includes: the task pool marking the first task as completed; and sending a notification that the first task is completed from the task pool to the CPU.

In an embodiment, the method further comprises: configuring the first unit to determine that the first unit has available processing power as a predicate to proactively send the first agent to the task pool.

In an embodiment, the method further comprises integrating the first unit into the first device prior to adding the programmed first unit to the network.

In an embodiment, the first device includes one of a sensor, a light bulb, a power switch, an appliance, a biometric device, a medical device, a diagnostic device, a laptop, a tablet, a smartphone, a motor controller, and a security device.

In an embodiment, adding the programmed first unit to the network includes establishing a communication link between the first unit and the task pool.

In an embodiment, the CPU is further configured to fill the task pool with a second task of a second task type, the method further comprising the steps of: programming the second unit to perform the second task type; A communication link is established with the task pool; a second agent is actively sent from the second unit to the task pool; the second agent searches for a second type of task in the task pool; the second agent retrieves a second task from the task pool; The second agent sends the second task to the second unit; the second unit processes the second task; a notification that the second task has been completed is sent from the second unit to the task pool; the task pool marks the second task as completed; and A notification that the second task has completed is sent from the task pool to the CPU.

Also provided is a system for controlling distributed processing resources in an Internet of Things (IoT) computing environment, the system comprising: a CPU configured to divide cluster computing requirements into tasks and place the tasks in a pool ; and a plurality of devices, each having a unique dedicated agent, configured to actively retrieve tasks from said pool without requiring direct communication with the CPU.

While there has been shown an enabling description of various embodiments including the best mode known to the inventors, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the scope of the invention. modifications, and equivalents may be substituted for various elements. Therefore, it is intended that the invention disclosed herein not be limited to the particular embodiments disclosed, but that the invention will include all embodiments falling within the words and equivalents of the claims.

Claims (20)

1. A processing system comprising: task pool; a controller configured to populate the task pool with a first task; and The first coprocessor is configured to actively retrieve the first task from the task pool. 2. The processing system of claim 1 , wherein the first co-processor includes a first agent configured to retrieve data from the task without communicating with the controller. The pool retrieves the first task. 3. The processing system of claim 2 , wherein the first task includes an identification of a first task type, the first coprocessor is configured to execute a task of the first type, and the first agent configured to search the pool of tasks for tasks of the first type. 4. The processing system of claim 1, wherein the first co-processor is further configured to process the first task and notify the task pool upon completion of the first task. 5. The processing system of claim 1, wherein the task pool is configured to notify the controller when the first task is completed. 6. The processing system of claim 1, wherein the controller and the first coprocessor are configured to communicate with each other only through the task pool. 7. The processing system of claim 1, wherein the controller and the first co-processor are configured to communicate with each other directly and through the task pool. 8. The processing system of claim 2, wherein the first co-processor is configured to determine that processing capacity is available, and to assign the agent to the task pool in response to the determination. 9. The processing system of claim 3, wherein the controller is further configured to populate the task pool with a second task, and wherein the system further comprises a second co-processing with a second agent The second agent is configured to actively retrieve the second task from the task pool. 10. The processing system of claim 9 , wherein the second task includes an identification of a second task type, the second coprocessor is configured to execute a task of the second type, and the second agent configured to search the pool of tasks for tasks of the second type. 11. The processing system of claim 1 , wherein the controller and the task pool are resident on a monolithic integrated circuit (IC), and the first coprocessor is not resident on the IC. superior. 12. The processing system of claim 9 , wherein the controller, the task pool, and the first coprocessor and the second coprocessor are resident on a monolithic integrated circuit (IC) . 13. A method of dynamically controlling processing resources in a network of a type comprising a central processing unit (CPU) configured to populate a task pool with a first task of a first task type, the method comprising The following steps: programming a first unit to perform said first task type; adding said programmed first unit to said network; actively sending a first agent from said first unit to said task pool; the first agent searches the task pool for tasks of a first type; the first agent retrieves the first task from the task pool; the first agent delivers the first task to the first unit; the first unit processes the first task; and A notification is sent from the first unit to the pool of tasks that the first task has been completed. 14. The method of claim 13 , further comprising: the task pool marking the first task as completed; and sending a notification from the task pool to the CPU that the first task is complete . 15. The method of claim 13, further comprising configuring the first unit to proactively send the first agent to the task pool based on a determination that the first unit has available processing power. 16. The method of claim 13, further comprising integrating the programmed first unit into the first device prior to adding the programmed first unit to the network. 17. The method of claim 16, wherein the first device comprises a sensor, a light bulb, a power switch, an appliance, a biometric device, a medical device, a diagnostic device, a laptop, a tablet, a smart phone, a motor One of the controller and safety device. 18. The method of claim 13, wherein adding the programmed first unit to the network comprises: A communication link is established between the first unit and the task pool. 19. The method of claim 13, wherein the (CPU) is further configured to populate the task pool with second tasks having a second task type, the method further comprising the step of: programming a second unit to perform said second task type; establishing a communication link between the second unit and the task pool; actively sending a second agent from the second unit to the pool of tasks; the second agent searches the task pool for tasks of a second type; the second agent retrieves the second task from the task pool; the second agent delivers the second task to the second unit; the second unit processes the second task; sending a notification from the second unit to the task pool that the second task has been completed; the task pool marks the second task as completed; and A notification is sent from the task pool to the CPU that the second task has completed. 20. A system for controlling distributed processing resources in an Internet of Things (IoT) computing environment, comprising: a CPU configured to divide the computing needs of the cluster into tasks and place the tasks in a pool; and A plurality of devices, each with a unique dedicated agent configured to actively retrieve tasks from the pool without requiring direct communication with the CPU.