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 .
Continued Examination Under 37 CFR 1.114 2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/17/2025 has been entered.
Claims 1-25 are presented for the examination.
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, 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, 8, 14, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Miloushev( US 20060143350 A1) view of McKee(US 20030115476 A1) in view of Winkeler(US 20020152280 A1) and further in view of Chalmer( US 6728962 B1) .
As to claim 1, Miloushev teaches in response to call, a first application programming interface (API) from a first software library to access a timeline semaphore created by a second from another API from a second different software library( the processes 251 and 252[second library ] are called member processes of the aggregated process 254[second library ]. The processes 250 and 251[API] interact with the operating system 230 through the API 270; the processes 252 and 253 interact with the operating systems 231 and 232, respectively, through the API 271 and 272, respectively, para[0185], ln 5-11/ in response to a request to create a semaphore coming from a thread in the member process 251, the operating system 230 has assigned a handle value 2243 to the semaphore represented by the entry 643. Similarly, in response to a request to create a semaphore coming from a thread in the member process 252, the operating system 231 has assigned the same handle value, 2243, to the semaphore represented by the entry 646. However, these are two different semaphores, allocated independently by threads running on the servers 200 and 201, respectively, para[0286]/ The agents 240, 241 and 242[first library] preferably intercept the operating system API 270, 271 and 272, respectively, in order to track resource requests made by processes that run on the servers 200, 201 and 202, respectively. The agents further communicate with the grid switch 210 using messages 260-263 through the connections 220, 221 and 222, para[0188], ln 1-8/ The agent[API] may call the original function before, after, in addition to or instead of its agent-provided functionality; or it may not call it at all, para[0249], ln 7-10/ the agent 240[first API]sends an access request to the grid switch. By the handle value 22, the grid switch locates the routing entry 644 which indicates that the semaphore is on the server 200 and therefore can be accessed[access]directly by that thread, and contains the locally assigned handle for that semaphore, 2243, para[0288], ln 1-8/ The synchronization object routing table 642 contains at least the following entries: entry 644 representing the semaphore with handle 22 and the entry 645 representing the semaphore with handle 23, para[0279], ln 6-10).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Tuan with Miloushev to incorporate above feature because this creates processes and resources, and for accessing resources transparently across multiple servers and increase the number of processors that work concurrently in the same system are needed in order to meet the needs for high-performance computing systems.
Mckee teaches destroy the timeline semaphore for a timeline semaphore indicated and created by first and second API from a first and second different software library and ( If a process calls routines[first software library] to access two different semaphores close in time, para[0038], ln 17-21/access to the semaphore itself is guarded by a mutex lock, spin lock, or other such device for guaranteeing that only one process or thread may access semaphore routines[first software library] at any particular instant in time, para[0003] , ln 23-28/ The class "semaphore" includes the following public function members[first software library]: (1) "init," declared above on line 14, that initializes the value and Memory_Address data members of the semaphore; …. (8) "lock," declared above on line 20, a basic semaphore routine that is called by a process or thread to acquire a grant for memory access from an instance of the class "semaphore, para[0058]/ the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region; (2) "destroySemaphore," declared above on line 28, that deallocates memory associated with the semaphore and then deallocates the semaphore itself, para[0046], ln 1-10/ the operating system may call kernel routines that execute at privilege level 0 in order to access resources protected from access by both application programs and operating systems, para[0023], ln 10-15/ calling semaphore routines, as well as into an internal data structure associated with the process or thread, and to remove the protection key from the protection-key register via a kernel-routine call, para[0033], ln 15-19/ The class "kernel" includes the following private member functions[first software library]: (1) "allocateProtectionKey" and "deallocateProtectionKey ……. "allocateSemaphore" and "deallocateSemaphore," declared above on lines 15 and 16, that allocate and deallocate instances of the class "semaphore," where the access rights to be associated with the memory including the semaphore are supplied as arguments for allocation and a pointer to an existing semaphore supplied as an argument for deallocation, para[0044], ln 1-21/ Finally, the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region, para[0046], ln 1-10/ On line 9, destroySemaphore attempts to gain access to semaphore routines via the semaphore function member "getSpinLock." If access to the semaphore is not obtained, then an error condition has occurred. Access has been denied because another process or thread is currently accessing the semaphore routines. However, the routine "destroySemaphore" should be called only after processes and threads no longer attempt to access the semaphore. Similarly, on line 13, destroySemaphore determines whether there are any processes or threads waiting in the wait queue associated with the semaphore. Again, if there are waiting processes or threads, then an error condition has occurred. In both cases, the error condition can be handled in many different ways. Generally, the semaphore can be destroyed after awakening any waiting processes, and subsequent errors caught through protection key faults, para[0063], ln 8-22).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Tuan and Miloushev with McKee to incorporate above feature because this employs hardware-based memory-protection facilities to enforce semaphore-based memory access control and detect programming errors involving failure to follow the semaphore protocol for obtaining and releasing access rights.
Winkeler teaches a first application programming interface (API) to access a timeline semaphore that is created and shared with the first API by a second API to synchronize the first API with the second API(data socket client calls or invokes[first/second API] the file adapter's Connect method The data socket client may also take other forms for different development environments, such as a LabVIEW Virtual Instrument (VI), a DLL (dynamic linked library), or an instrument driver/DLL among others. In The first computer system 82 and/or second computer system 86 may each include or store a first software component[first/second API], preferably a data socket client[first/second API] (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client[first API] according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first library] that are operable to connect, access[access], and/or convert data located in a semaphore, para[0031], ln 1-14/ the semaphore may be read from and/or written to by the first computer system and/or the second computer system (i.e., by applications executing on the first computer system and/or the second computer system) for use by a desired application, or to maintain desired communication, synchronization, or control. When a data socket client accesses (reads or writes) a semaphore, the data socket client performs various operations which greatly simplify this data access. For example, the data comprised in the semaphore may be of a first data type of a plurality of different possible data types. An application program may invoke the data socket client when the semaphore is desired to be accessed, and the data socket client may access the semaphore using location information of the semaphore (e.g., a uniform resource locator (URL) specifying a location of the semaphore). The data socket client may access the data comprised in the semaphore, para[0069],ln 1- 18/ The first computer system 82 and/or second computer system 86 may each include or store a first software component[second API], preferably a data socket client (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first/second API] that are operable to connect, access[access], and/or convert[create] data located in a semaphore, para[0031], ln 1-14/ two difference devices may use a semaphore to communicate, synchronize operations or share data between them, wherein applications (e.g., embedded applications) executing on each device may use a data socket client[first/second API] for accessing the semaphore., para[0055], ln 12-20/ involve a plurality of applications in a corresponding plurality of computer systems, where each of the applications share or use a semaphore for communication and/or data exchange. Each of the applications may include a software component, such as a data socket client[first/second API]. In this typical embodiment, one or more requests to perform a locked read-modify-write operation on the data comprised in the semaphore may be received from one or more of the multiple software components. When multiple requests are received, the plurality of requests may be stored in a queue, and processed sequentially. The corresponding multiple of applications may use the semaphore to synchronize operation of the applications or otherwise provide communication between the applications. The multiple of computer systems and the computer memory may be connected through a network (e.g., the Internet). Accessing data from a semaphore in a computer system may include publishing or writing data to the semaphore as well as reading data from the semaphore, para[0009]/ The first computer system 82 and the second computer system 86 may each store an application program (or a plurality of application programs), wherein the application program(s) on each computer may use a semaphore to communicate with each other, synchronize operations, or otherwise share data. One or more of the first computer system 82 or the second computer system 86, or another computer (not shown) may store the semaphore that is used by the respective application programs, para[0030] ).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Miloushev and McKee with Winkeler to incorporate above feature this maintains and/or accesses a semaphore, wherein various devices may use the semaphore for synchronization or control for various purposes.
Chalmer teaches synchronize a first workload associated with the first API with a second workload associated with the second API; and destroy the timeline semaphore(the processor 22 may be any one of a number of conventional, commercially available, processor devices (with corresponding support and interface circuitry), col 4, ln 54-62/A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function[second API]. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call[first API]), col 17, ln 43-56/ process pends on a semaphore through the use of the sempend(S) call[first API], where S is a valid semaphore value returned from a previously invoked semcreate( ) call[second API], col 17, ln 55-60).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Miloushev, McKee and Winkeler with Chalmer to incorporate above feature this allows the scheduling algorithm to determine which process will in fact run next.
As to claims 8, 14, 21, they are rejected for the same reason as to claim 1 above.
Claims 2-6, 9, 10, 11, 12,13, 15, 16, 17, 18, 19, 22, 23-24 are rejected under 35 U.S.C. 103 as being unpatentable over Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Winkeler(US 20020152280 A1) in view of Chalmer( US 6728962 B1) and further in view of Kouznetsov(US 7254811 B2).
As to claim 2, Miloushev teaches the first API is a first API and corresponds to a first context using the first software library, second API and corresponds to a second context using the second software library( para[0185], ln 5-11/ para[0288], ln 1-8) for the same reason as to claim 1 above and Kouznetsov teaches the API is a first API and corresponds to a first context, wherein the other API is a second API and corresponds to a second context, and wherein to invalidate is to release references of the timeline semaphore in the first context( FIG. 12 illustrates one exemplary configuration API call sequence 1200, in accordance with one embodiment. As shown, MDoConfigOpen( ) 830 returns a handle to be passed to the configuration retrieval and specification functions. MDoConfigClose( ) 814 is used to release and close the configuration handle returned by MDoConfigOpen( ) 812. MDoConfigSet( ) 818 sets a specified configuration variable with a specified value, and MDoConfigGet( ) 816 returns a configuration value for a specified variable, col 14, ln 53-65/ Return Value Semaphore handle if successful, INVALID_AL_SEM_HANDLE otherwise. See Also AlSemCreate( ), AlsemClose( ), AlSemGet( ), AlSemRelease( ) AlSemClose Description Closes and releases system resource associated specified semaphore handle. Semaphore usage/reference count is also decremented, and the referenced semaphore object is destroyed if the count reaches zero. Prototype void AlSemClose(AL_SEM_HANDLE hSem), col 34, ln 5-32).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Miloushev, McKee, Winkeler and Chalmer with Kouznetsov to incorporate the feature of the API is a first API and corresponds to a first context, wherein the other API is a second API and corresponds to a second context, and wherein to invalidate is to release references of the timeline semaphore in the first context Kouznetsov because this provides Resource synchronization and control is done using a semaphore.
As to claim 3, Kouznetsov teaches to invalidate the timeline semaphore further comprises to release references to the timeline semaphore corresponding to the second API in the second context using the second software library( col 33, ln 45-60/ col 34, ln 5-32) for the same reason as to claim 2 above.
As to claim 4, Kouznetsov teaches destroying the timeline semaphore from the second API is to delete a handle of the timeline semaphore, wherein the handle is to reference an exported handle from the second API, and wherein the second API created the handle( col 34, ln 1-30) for the same reason as to claim 2 above.
As to claim 5, Miloushev teaches the second API created the timeline semaphore( para[0286]).
As to claim 6, Mckee teaches to destroy the timeline semaphore, and wherein to destroy is to occur after all operations waiting on or signaling the timeline semaphore are completed( para[0033], ln 15-1 ) and Kouznetsov teaches to destroy the timeline semaphore is to remove any references to the timeline semaphore ( col 34, ln 25-32) for the same reason as to claims 1 and 2 above.
As to claims 9, 11, 12, 13, 15, 17, 18, 19, they are rejected for the same reasons as to claims 2, 4, 5, 6 above.
As to claim 10, Kouznetsov teaches invalidate the timeline semaphore further comprises to release references of the timeline semaphore in the second context ( col 33, ln 45-60/ col 34, ln 5-32) for the same reason as to claim 2 above.
As to claim 16, 23, 24, they are rejected for the same reasons as to claims 10, 3, 4, 11 above.
As to claim 22, Kouznetsov teaches the API corresponds to a first context, wherein the other API corresponds to a second context, and wherein the method further comprises: releasing references of the timeline semaphore in the first context( col 14, ln 53-65/ col 34, ln 5-32) for the same reason as to claim 2 above.
Claims 7, 20 are rejected under 35 U.S.C. 103 as being unpatentable over
Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Winkeler(US 20020152280 A1) in view of Chalmer( US 6728962 B1) in view of Hipp(US 20050010924 A1) and further in view of Tuan (US 20060136640 A1).
As to claim 7, Hipp teaches operations( operating system API interfaces 210, and process management subsystem 216. If the state has changed since the last snapshot (step 270), the new state is recorded. Control then loops to step 264 and executes through the above sequence of steps until all states of all processes are checked. Once completed, control proceeds to step 278, the registered global state, such as semaphores, is removed, para[0031], ln 9-18).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Tuan, Miloushev, McKeeand, Winkeler and Chalmer with Hipp to incorporate the feature of operations because this provides need for a system and method for effecting a transfer of applications across computer networks without incurring costly processing overhead.
Tuan teaches destroy the timeline semaphore is to occur after a context has completed all operations that reference the timeline semaphore( para[0002], ln 5-9 to para[0003] , para[004]. Para[0005]).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Miloushev, McKeeand, Winkeler , Chalmer and Hipp with Tuan to incorporate the feature of operations because this acquires the corresponding semaphore of that shared resource.
As to claim 20, it is rejected for the same reason as to claim 7 above.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over
Miloushev( US 20060143350 A1) in view of McKee(US 20030115476 A1) in view of Winkeler(US 20020152280 A1) in view of Chalmer( US 6728962 B1) and further in view of Yamamoto(US 20060287820 Al).
As to claim 25, Yamamoto teaches removing all references to the timeline semaphore( The OS_Semaphore_Delete( ) function uses an operating system service to delete a Semaphore object. The function is called by the GPS engine at the stopping procedure to delete all used semaphores. TABLE-US-00096 TABLE 96 File gps_rtos.c Syntax tGPS_UINT32 OS_Semaphore_Delete( tGPS_SEMAPHORE sem_handle ) Parameter Data range Units Description sem_handle Semaphore object handlepara[0138], ln 1-6).
It would have been obvious to one of the ordinary skill in the art at the time the invention was made to modify the teaching of Miloushev, McKee, Winkeler and Chalmer with Hipp to incorporate the above feature because this exists for implementations of SPS solutions that overcome the problems noted above and others previously experienced.
Response to the argument:
6. Applicant amendment filed on 12/03/2025 has been considered but they are not persuasive:
Applicant argued in substance that :
(1) “ However, the cited portions of Winkeler at least fail to teach or suggest an API, a first and second API, and sharing between a first and second API, let alone "execute a first application programming interface (API) from a first software library to access a timeline semaphore that is created and shared with the first API by a second API from a second different software library to synchronize a first workload associated with the first API with a second workload associated with the second API," as claimed..”.
7. Examiner respectfully disagreed with Applicant's remarks:
As to the point (1), Mckee teaches If a process calls routines[first software library] to access two different semaphores close in time, para[0038], ln 17-21/access to the semaphore itself is guarded by a mutex lock, spin lock, or other such device for guaranteeing that only one process or thread may access semaphore routines[first software library] at any particular instant in time, para[0003] , ln 23-28/ The class "semaphore" includes the following public function members[first software library]: (1) "init," declared above on line 14, that initializes the value and Memory_Address data members of the semaphore; …. (8) "lock," declared above on line 20, a basic semaphore routine that is called by a process or thread to acquire a grant for memory access from an instance of the class "semaphore, para[0058]/ the class "kernel" includes the following public member functions[second software library]: (1) "create Semaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region; (2) "destroySemaphore," declared above on line 28, that deallocates memory associated with the semaphore and then deallocates the semaphore itself, para[0046], ln 1-10/ the operating system may call kernel routines that execute at privilege level 0 in order to access resources protected from access by both application programs and operating systems, para[0023], ln 10-15/ calling semaphore routines, as well as into an internal data structure associated with the process or thread, and to remove the protection key from the protection-key register via a kernel-routine call, para[0033], ln 15-19/ The class "kernel" includes the following private member functions[first software library]: (1) "allocateProtectionKey" and "deallocateProtectionKey ……. "allocateSemaphore" and "deallocateSemaphore," declared above on lines 15 and 16, that allocate and deallocate instances of the class "semaphore," where the access rights to be associated with the memory including the semaphore are supplied as arguments for allocation and a pointer to an existing semaphore supplied as an argument for deallocation, para[0044], ln 1-21/ Finally, the class "kernel" includes the following public member functions[second software library]: (1) "createSemaphore," declared above on line 26, that creates an instance of the class semaphore according to a specified semaphore value, a specified number of pages in the memory region that the semaphore is created to protect, and access rights to be associated with both the semaphore and the protected memory region, para[0046], ln 1-10/ On line 9, destroySemaphore attempts to gain access to semaphore routines via the semaphore function member "getSpinLock." If access to the semaphore is not obtained, then an error condition has occurred. Access has been denied because another process or thread is currently accessing the semaphore routines. However, the routine "destroySemaphore" should be called only after processes and threads no longer attempt to access the semaphore. Similarly, on line 13, destroySemaphore determines whether there are any processes or threads waiting in the wait queue associated with the semaphore. Again, if there are waiting processes or threads, then an error condition has occurred. In both cases, the error condition can be handled in many different ways. Generally, the semaphore can be destroyed after awakening any waiting processes, and subsequent errors caught through protection key faults, para[0063], ln 8-22)and,
Winkeler teaches data socket client calls or invokes[first/second API] the file adapter's Connect method The data socket client may also take other forms for different development environments, such as a LabVIEW Virtual Instrument (VI), a DLL (dynamic linked library), or an instrument driver/DLL among others. In The first computer system 82 and/or second computer system 86 may each include or store a first software component[first/second API], preferably a data socket client[first/second API] (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client[first API] according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first library] that are operable to connect, access[access], and/or convert data located in a semaphore, para[0031], ln 1-14/ the semaphore may be read from and/or written to by the first computer system and/or the second computer system (i.e., by applications executing on the first computer system and/or the second computer system) for use by a desired application, or to maintain desired communication, synchronization, or control. When a data socket client accesses (reads or writes) a semaphore, the data socket client performs various operations which greatly simplify this data access. For example, the data comprised in the semaphore may be of a first data type of a plurality of different possible data types. An application program may invoke the data socket client when the semaphore is desired to be accessed, and the data socket client may access the semaphore using location information of the semaphore (e.g., a uniform resource locator (URL) specifying a location of the semaphore). The data socket client may access the data comprised in the semaphore, para[0069],ln 1- 18/ The first computer system 82 and/or second computer system 86 may each include or store a first software component[second API], preferably a data socket client (or data socket component), according to one embodiment of the present invention. Applications executing in the first computer system 82 and the second computer system 86 are each operable to use their respective data socket client according to the present invention to access data located in the semaphore. The first software component[first/second API] may be any of various types of software components[first/second API] that are operable to connect, access[access], and/or convert[create] data located in a semaphore, para[0031], ln 1-14/ two difference devices may use a semaphore to communicate, synchronize operations or share data between them, wherein applications (e.g., embedded applications) executing on each device may use a data socket client[first/second API] for accessing the semaphore., para[0055], ln 12-20/ involve a plurality of applications in a corresponding plurality of computer systems, where each of the applications share or use a semaphore for communication and/or data exchange. Each of the applications may include a software component, such as a data socket client[first/second API]. In this typical embodiment, one or more requests to perform a locked read-modify-write operation on the data comprised in the semaphore may be received from one or more of the multiple software components. When multiple requests are received, the plurality of requests may be stored in a queue, and processed sequentially. The corresponding multiple of applications may use the semaphore to synchronize operation of the applications or otherwise provide communication between the applications. The multiple of computer systems and the computer memory may be connected through a network (e.g., the Internet). Accessing data from a semaphore in a computer system may include publishing or writing data to the semaphore as well as reading data from the semaphore, para[0009]/ The first computer system 82 and the second computer system 86 may each store an application program (or a plurality of application programs), wherein the application program(s) on each computer may use a semaphore to communicate with each other, synchronize operations, or otherwise share data. One or more of the first computer system 82 or the second computer system 86, or another computer (not shown) may store the semaphore that is used by the respective application programs, para[0030] ).
Chalmer teaches A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function[second API]. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call[first API]), col 17, ln 43-56/ process pends on a semaphore through the use of the sempend(S) call[first API], where S is a valid semaphore value returned from a previously invoked semcreate( ) call[second API], col 17, ln 55-60).
Conclusion
US 7296271 B1 teaches A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call.)
US 20060085679 A1 teaches System V semaphores are a synchronization primitive that can be shared across multiple processes. The kernel maintains these semaphores, and provides system calls to create, open, or modify a set of semaphores. These system calls are semget( ), semctl( ), and semop( ). See the Linux manual for further information.
US 20230138635 A1 teaches These command lists reside in single source file, and provide execution of workloads that are implicitly synchronized by semaphores (e.g., signals). For example, semaphore wait and semaphore signal can be achieved by hardware commands MI_SEMAPHORE_WAIT and MI_SEMAPHORE_SIGNAL or MI_STORE_DATA_IMM (which stores value in memory). The producer workload performs computations and once the kernel is finished, then it signals the consumer to perform the consumer workload on a selected data chunk (e.g., the scratch memory). Then it waits for the consumer to signal it has finished the processing. At the end, the producer signal via global variable “stop” the workload is done.
US 7254811 B2 teaches Resource synchronization and control is done using a semaphore. Included in the abstraction library is a set of functions to create, open, close and modify a semaphore object. Below is an exemplary semaphore API.
US 7545380 B1 teaches Before allowing GPU 1 to proceed with such processing, flip( ) attempts to acquire the semaphore for image 1, using the function Semaphore.Acquire( ). Here, the semaphore for image 1 has not yet been released with respect to the processing of GPU 0, and the function Semaphore.Acquire( ) simply does not return until the semaphore is acquired. Thus, flip( ) hangs until the semaphore for image 1 is acquired. Only then is the function GPU(i).Display(NewBuffer) called.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Young Kevin can be reached on (571)270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LECHI TRUONG/ Primary Examiner, Art Unit 2194
US 7296271 B1 A semaphore may be an integer value which represents a queue of processes. The semaphore may be created by the use of a semcreate( ) function. Semaphore synchronization may allow one or more processes to pend on a particular semaphore value. That is, a process will block and wait for another process to post to that same semaphore. Each process which pends on a particular semaphore is placed into a FIFO queue of processes associated with the semaphore. Each time another process posts to the semaphore, the process at the head of the FIFO queue is unblocked. The unblocked process will run as soon as the scheduler allows it. (Note that any process may create a semaphore to which any process may pend, post, or which any process may delete using the semdelete(S) call.)
US 20060085679 A1 System V semaphores are a synchronization primitive that can be shared across multiple processes. The kernel maintains these semaphores, and provides system calls to create, open, or modify a set of semaphores. These system calls are semget( ), semctl( ), and semop( ). See the Linux manual for further information.
US 20230138635 A1 These command lists reside in single source file, and provide execution of workloads that are implicitly synchronized by semaphores (e.g., signals). For example, semaphore wait and semaphore signal can be achieved by hardware commands MI_SEMAPHORE_WAIT and MI_SEMAPHORE_SIGNAL or MI_STORE_DATA_IMM (which stores value in memory). The producer workload performs computations and once the kernel is finished, then it signals the consumer to perform the consumer workload on a selected data chunk (e.g., the scratch memory). Then it waits for the consumer to signal it has finished the processing. At the end, the producer signal via global variable “stop” the workload is done.
US 7254811 B2 Resource synchronization and control is done using a semaphore. Included in the abstraction library is a set of functions to create, open, close and modify a semaphore object. Below is an exemplary semaphore API.
US 7545380 B1Before allowing GPU 1 to proceed with such processing, flip( ) attempts to acquire the semaphore for image 1, using the function Semaphore.Acquire( ). Here, the semaphore for image 1 has not yet been released with respect to the processing of GPU 0, and the function Semaphore.Acquire( ) simply does not return until the semaphore is acquired. Thus, flip( ) hangs until the semaphore for image 1 is acquired. Only then is the function GPU(i).Display(NewBuffer) called, which
creates semaphore(s) used to ensure synchronous access by concurrent threads to data in shared memory, before continuing to block 1222. Shared memory data accesses appropriately utilize semaphore lock windows (semaphore(s) created at block 1220) for proper access. In one embodiment, block 1220 creates a single semaphore for all shared memory accesses, but this can deteriorate performance of threads accessing unrelated data. In the preferred embodiment, there is a semaphore for each reasonable set of data of shared