Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-5, 7-14 and 16-21 are currently pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 10-16 and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Wen et al. (U.S. Pub. No. 20090125907 A1) in view of Lee et al. (U.S. Pub. No. 20200326988 A1), further in view of Welc et al. (U.S. Pub. No. 20100162247 A1), and further in view of Neema et al. (U.S. Pub. No. 8161436 B1).
Wen, Lee and Welc were cited in a previous office action.
As per claim 1, Wen teaches the invention substantially as claimed including a processing method comprising:
dispatching, by an accelerated processor (par. 0014 XMT system includes at least one processor [equiv. accelerator processor]), a parent … [thread] of the program to be executed on one or more compute units of a plurality of compute units of the processor, the parent work group comprising a first plurality of work items (par. 0006 a thread control unit (TCU) executes an individual thread; par. 0028 A thread that includes a nested SPAWN-type command is called a parent thread [parent workgroup]; par. 0014 The XMT system includes at least one processor, a plurality of thread control units (TCUs) [plurality of compute units] each having an associated ID (TCU-ID));
executing, by at least one of the one or more compute units, a spawn work group instruction that pauses execution of the of the parent work group and enables a child work group of the parent work group to be executed on the one or more compute units of the plurality of compute units, the child work group comprising a second plurality of work items (par. 0046 Upon encountering a SPAWN command [instruction], the MTCU 104 retrieves the parallel segment positioned between the SPAWN command and a JOIN command, inclusive. The SCU 142 of the MTCU 104 initiates spawning of the parallel segment into a plurality of child threads; par. 0028 A thread generated as the result of execution of the nested SPAWN-type command is called a child thread, where the child thread is a child of the parent thread), wherein the spawn work group instruction includes … for controlling resumption of the parent work group and the parent work group is context switched out of the one or more compute units upon execution of the spawn work group instruction (par. 0048 TCUs continue to execute virtual threads associated with the SPAWN command until all of the virtual threads have been executed, at which point all of the TCUs will be in a sleep state. The MTCU 104 monitors when all of the TCUs are in a sleep state, at which point it returns to serial mode; par. 0005 The Spawn command is involved in facilitating transition from serial mode to parallel mode in which a plurality of parallel threads can operate concurrently. Each thread terminates with a Join command. Once all parallel threads have terminated, transition from parallel mode to serial mode occurs);
dispatching, by the accelerated processor, the child work group for execution to the one or more compute units of the plurality of compute units … (0047 The PSFU 130 allocates the virtual threads spawned from the SPAWN command to the TCUs,).
executing, on the one or more compute units, the child work group (par. 0047 … the individual TCUs execute their respective threads concurrently).
Wen does not expressly disclose: dispatching … when a sufficient amount of resources are determined to be available to execute the child work group.
However, Lee teaches: dispatching … when a sufficient amount of resources are determined to be available to execute the child work group (par. 0047 The system of FIG. 3 includes services and components. For example, the admission control component (222) delays/limits workflows until there are sufficient resources to run the workflow, at which time it admits work as resources become available; page 13, claim 9, monitoring, by an admission controller of the execution platform, resource availability on the execution platform for executing the first workflow definition; and upon determining, by the admission controller, that sufficient resources are available on the execution platform for executing the first workflow definition).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Wen by incorporating the method of waiting for sufficient resources to become available to run the workflow as set forth by Lee because it would provide for waiting to execute spawned child threads until sufficient resources are available to properly execute the child threads, with predictable results.
Wen and Lee do not expressly disclose:
dispatching, by an accelerated processor, a parent work group … the parent work group comprising a first plurality of work items; a spawn work group instruction that pauses execution of the parent work group and enables a child work group of the parent work group to be executed; resuming, by the one or more compute units, execution of the parent work group by context switching the parent work group back in, wherein the resuming is performed in response to determining the child work group updated the synchronization variable identified associated with the pointer in the spawn work group instruction.
However, Welc teaches: dispatching, by an accelerated processor, a parent work group … the parent work group comprising a first plurality of work items (par. 0014 In one embodiment, in response to executing a parent transaction, a first group [parent group] of one or more concurrent threads including a first thread is created; par. 0047, and Fig. 2, describe creating a first thread team comprising child thread 203 and 204 [equiv. to parent group] to perform computations for a parent transaction on processor cores 810, 820 of a multi-core processor [accelerator] as in Fig. 8; Par. 0048 further describes, child thread 203 [of the parent group] further spawns two other child threads (209 and 210) [equiv. to child group] at fork point 221. Child thread 209 and child thread 210 join at join point 222 upon completing the execution. Subsequently, child thread 203 and child thread 204 join at join point 223); a spawn work group instruction that pauses execution of the parent work group … (par 0047 In one embodiment, processing logic suspends the execution of parent transaction 201 before spawning off child threads 203-204);
resuming, by the one or more compute units, execution of the parent work group by context switching the parent work group back in … (par. 0047 … In one embodiment, processing logic resumes execution of parent transaction 201 after child threads complete their execution; par. 0049 processing logic resumes parent transaction 201 (from being suspended) at join point 223 after the computation performed by the thread team is completed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Wen and Lee by incorporating method executing nested concurrent threads as set forth by Welc because it would provide for spawning child thread group for a parent thread group. This would have resulted in increased performance for large transactions.
Wen, Lee and Welc do not expressly describe: resuming, by the one or more compute units, execution of the parent work group … in response to determining the child work group updated the synchronization variable associated with the pointer in the spawn work group instruction.
However, Neema teaches: resuming, by the one or more compute units, execution of the parent work group … in response to determining the child work group updated the synchronization variable identified associated with the pointer in the spawn work group instruction (col. 13, lines 44-47 and resume execution of the parent process in response to adjustments to the first variable by the free-running processes indicating that the free-running processes have completed; col. 11, lines 40-45 In this manner, when one of the created free-running processes completes, the value of the synchronization variable is decremented and becomes equal to the value of zero. The parent process is triggered to resume execution concurrently with the unfinished free-running processes. Here, implicitly includes a reference/pointer to the location of the variable in order to determine adjustments to the variable).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Wen, Lee and Welc by incorporating the technique of resuming parent process execution as set forth by Neema because it would provide for effectively resuming execution a parent process group in response to adjustments to the first synchronization variable indicating child processes have completed.
As per claim 2, Wen, Lee and Welc teaches the limitations of claim 1. Lee further teaches: determining, by the accelerated processor, whether or not the sufficient amount of resources are available to execute the child work group prior to dispatching the child work group for execution on the one or more compute units; and when the sufficient amount of resources are determined to be unavailable to execute the child work group, waiting until the sufficient amount of resources are available to dispatch the child work group for execution on the one or more compute units (par. 0047 The system of FIG. 3 includes services and components. For example, the admission control component (222) delays/limits workflows [waits] until there are sufficient resources to run the workflow, at which time it admits work as resources become available; page 13, claim 9, monitoring, by an admission controller of the execution platform, resource availability on the execution platform for executing the first workflow definition; and upon determining, by the admission controller, that sufficient resources are available on the execution platform for executing the first workflow definition, launching one or more workflow executors to execute the first workflow definition).
As pe claim 3, Lee further teaches wherein determining whether or not the sufficient amount of resources are available to execute the child work group comprises determining whether or not the one or more compute units and work group context memory, to be accessed by work-items of the child work group, are available (page 13, claim 9, … upon determining, by the admission controller, that sufficient resources are available on the execution platform for executing the first workflow definition, launching one or more workflow executors to execute the first workflow definition; par. 0039 TCUs may each have their own dedicated resources (e.g., function unit, registers, instruction memory, buffers, etc.)).
As per claim 4, Wen teaches wherein the work group context memory comprises at least one of registers and local data store (LDS) memory (par. 0033 Each memory module 120 includes register file 122 having at least one local register, a TCU instruction cache 124, and at least one read buffer 126).
As per claim 5, Wen further teaches: the method further comprises executing by the accelerated processor, a join workgroup instruction which comprises the pointer to the synchronization variable in the spawn work group instruction (par. 0027 In the current example the XMT capability is supported by using single program multiple data (SPMD) processing Virtual threads are executed in parallel, including transitioning from parallel to serial processing, and vice versa using SPAWN and JOIN commands).
As per claim 7, Wen further teaches wherein the resources are allocated by the accelerated processor which dispatches the parent work group and the child work group for execution (par. 0046 The SCU 142 of the MTCU 104 initiates spawning of the parallel segment into a plurality of child threads; par. 0039 The scheduling of the memory resources may be centralized or decentralized).
As per claim 10, it is a processing apparatus having similar limitations as claim 1. Thus, claim 10 is rejected for the same rationale as applied to claim 1. Wen further teaches: memory; and a processor (par. 0014 at least one processor; par. 0037 a computer-readable medium, such as RAM; par. 0001 a number of CPU cores provided on a single chip [equiv. accelerator processor]).
As per claim 11, it is a processing apparatus having similar limitations as claim 2. Thus, claim 11 is rejected for the same rationale as applied to claim 2.
As per claim 12, it is a processing apparatus having similar limitations as claim 3. Thus, claim 12 is rejected for the same rationale as applied to claim 3.
As per claim 13, it is a processing apparatus having similar limitations as claim 4. Thus, claim 13 is rejected for the same rationale as applied to claim 4.
As per claim 14, it is a processing apparatus having similar limitations as claim 5. Thus, claim 14 is rejected for the same rationale as applied to claim 5.
As per claim 16, it is a processing apparatus having similar limitations as claim 7. Thus, claim 16 is rejected for the same rationale as applied to claim 7.
As per claim 19, it is a non-transitory computer readable medium having similar limitations as claim 1. Thus, claim 19 is rejected for the same rationale as applied to claim 1.
As per claim 20, it is a non-transitory computer readable medium having similar limitations as claim 2. Thus, claim 20 is rejected for the same rationale as applied to claim 2.
As per claim 21, Wen further teaches: wherein the parent work group comprises a first plurality of work-items to be executed and the child work group comprises a second plurality of work-items to be executed (par. 0014 at least one TCU executes a parent child thread of the plurality of child threads that includes a nested spawn-type command for spawning additional child treads of the plurality of child threads. The parent child thread is related in a parent-child relationship a child thread including the nested spawn-type command being a parent thread to the child threads that are spawned in conjunction with the nested spawn-type command. Wherein each parent tread and child thread inherently comprise or are composed of a plurality of instructions to be executed by TCUs/processor units).
Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Wen in view of Lee, Welc and Neema as applied to claims 1, 10 and 19, and further in view of Piira et al. (U.S. Pub. No. 20130061234 A1).
Piira was cited in a previous office action.
As per claim 8, Wen further teaches wherein the program is a kernel and an amount of resources are allocated to execute a plurality of work groups for the kernel (par. 0081 operating system of the XMT system for allocating space), and the method further comprises:
Wen, Lee, Welc and Neema do not expressly teach: executing, on the one or more compute units, the parent work group; when a sufficient amount resources is determined to be available to execute the plurality of work groups, continuing execution of the parent work group; and when the sufficient amount resources is determined not to be available to execute the plurality of work groups, context switching-out the parent work group.
However, Piira teaches: executing, on the one or more compute units, the parent work group; when a sufficient amount resources is determined to be available to execute the plurality of work groups, continuing execution of the parent work group; and when the sufficient amount resources is determined not to be available to execute the a plurality of work groups, context switching-out the parent work group (par. 0038 If the determination indicates that there are insufficient computing resources for running instances MPI(1), . . . , MPI(N) [equiv. to plurality of work groups], the instance manager 270 can take action to release computing resources from the given instance [equiv. to parent workgroup] and other instances, which are running at the time of the determination, so that, for example, the given instance can keep running. Alternatively, when no additional computing resources can be accessed, instance manager 270 can shut down the given instance … of the media player).
It would have been obvious to one of ordinary skill in the art before the effective filing dates of the claimed invention to modify the teaching of Wen, Lee, Welc and Neema by incorporating the method of shutting down an instance when insufficient resources area available for a particular set of instances as set forth by Piira because providing the ability to exit/shut down a parent work group would have ensured there are sufficient resources available for executing spawned threads.
As per claim 9, Wen further teaches wherein an amount of memory is allocated for a threshold number of work groups for the kernel, and the method further comprises: determining whether a number of work groups currently executing for the kernel is less than the threshold number of work groups; when the number of work groups currently executing for the kernel is less than or equal to the threshold number of work groups, continuing execution of the child work group; and when the number of work groups currently executing for the kernel is greater than the threshold number of work groups (par. 0028 The number of threads to be generated from the SPAWN command are specified by an attribute of the SPAWN command. Par. 0065 When the number of virtual threads spawned exceeds the number of TCUs, at least some of the TCUs will execute multiple iterations). Piira teaches: allocating additional memory (par.0018 include allocating the requested increase in computer resources consumption in response to determining that the computer resources consumption would be less than the first predetermined level; 0040] Memory manager 260 can allocate memory for all player instances MPI(1), . . . , MPI(N) from a shared pool of memory).
As per claim 17, it is a processing apparatus having similar limitations as claim 8. Thus, claim 17 is rejected for the same rationale as applied to claim 8.
As per claim 18, it is a processing apparatus having similar limitations as claim 9. Thus, claim 18 is rejected for the same rationale as applied to claim 9.
Response to Arguments
Applicant's arguments filed 06/12/2025 have been fully considered but they are not persuasive.
(1) The applicant argues in page 15 for claim 1, that Wen “lacks any disclosure of hardware-level context switching of a parent thread or work group in response to the execution of a SPAWN instruction”
As per point 1, the examiner respectfully disagrees because the combination of prior art cited reasonably teaches all the limitations as claimed. For example, Wen, par. 0005, clearly teaches using a Spawn command to facilitate transitioning from serial mode to parallel mode, and transition from a parallel mode back to a serial mode upon detecting execution of Join instruction, which is equivalent to context switching a parent thread in response to execution of an instruction [Join]. While Wen does not expressly describe context switching of a parent thread, Wen clearly teaches executing a Join instruction, upon detecting completion of spawned threads, to transition back to a serial mode [parent thread], which accomplishes the same technical solution of switching between execution of a parent thread group and child thread group. Further, in regards to arguments “Wen lacks any disclosure of hardware-level context switching”, nothing in the claims require that context switching is done in hardware-level. Thus, Applicant’s arguments are not persuasive.
(2) The applicant argues in pages 16-17 for claim 1, that neither Wen or Neema teach “resuming, by the one or more compute units, execution of the parent work group by context switching the parent work group back in, wherein the resuming is performed in response to determining the child work group updated the synchronization variable associated with the pointer in the spawn work group instruction”
As per point 2, the examiner respectfully disagrees because Neema, (col. 13, lines 41-47) clearly teaches a method that includes suspending execution of a parent process in response to the parent process initializing the first variable, and subsequently resume execution of the parent process in response to adjustments to the first variable by the free-running processes indicating that the free-running processes have completed execution. Although, Neema does not describe performing context switching, Neema’s suspending the parent process in order to execute free-running processes and resuming the parent process upon completion of the free-running processes is equivalent to context switching out the parent process, executing the free-running process, and context switching back in the parent process upon completion of the free-running processes to resume execution of the parent process and achieves the same result. Further, although, it not expressly described, it implicitly includes a reference/pointer to the location of the variable in order to determine adjustments to the variable. Therefore, Applicant’s arguments are not persuasive.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 20060235927 A1 teaches system and method for synchronizing distributed data streams for automating real-time navigation through presentation slides.
NPL prior art teaches “Explicit Multi-Threading (XMT) Bridging Models for Instruction Parallelism”
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Willy W. Huaracha whose telephone number is (571)270-5510. The examiner can normally be reached on M-F 8:30-5:00pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached on (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WH/
Examiner, Art Unit 2195
/BING ZHAO/Primary Examiner, Art Unit 2151