Handling process thread ownership

Abstract

The present disclosure relates to handling ownership of process threads. Examples of handling ownership of process threads include acquiring ownership of a set of process threads to assign ownership of a subject process thread to an ownership agent. In some examples, acquiring ownership may include acquiring ownership of a process thread by waiting for an event. During the acquisition of ownership of the set of process threads, one or more acquired process threads may be released to attend to an event that has occurred. A thread coordinator that handles ownership during the acquisition phase may release and re-bid one or more process threads. After all process threads are acquired, ownership of the subject process thread is assigned to an ownership agent. Through a set of ownership conditions, the process threads may be efficiently acquired in a shorter time and deadlock may be reduced.

Description

Background Art

[0001] Generally, an operating system may serve as an interface between a user and hardware and software resources. An operating system performs various tasks including process management, thread management, etc. Some operating systems may not have interruptible system calls. Mission-critical systems may be one of the examples that incorporate such an operating system. These systems have an operating system that is capable of utilizing the associated hardware capabilities. Mission-critical systems are popular because they serve industry requirements related to critical applications that require high availability, among other features. Mission-critical operating systems may be used without interruptible system calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present subject matter is described in detail according to one or more different examples with reference to the following drawings. The drawings are provided for illustrative purposes only and depict examples only, in which:

[0003] Figure 1 An example computing device according to the present subject matter is illustrated;

[0004] Figure 2 illustrates a schematic block diagram of an example computing device according to the present subject matter;

[0005] Figure 3A A schematic diagram illustrating a process and a set of process threads according to an example of the present subject matter;

[0006] FIG. 3B to FIG. 3F A diagram illustrating an example of handling ownership of a process thread according to the present subject matter;

[0007] Figure 3G and Figure 3H A schematic diagram illustrating an example of handling ownership of process threads by a thread coordinator according to the present subject matter; and

[0008] Figure 4A and Figure 4B An example flow diagram corresponding to handling ownership of a process thread in accordance with the present subject matter is illustrated. DETAILED DESCRIPTION

[0009] Typically, an operating system including a mission-critical operating system can run processes. A system with a mission-critical operating system may include hardware resources, such as a processor, memory, etc. The operating system may be able to manage and utilize hardware resources to run certain programs or applications. Each program / application may contain one or more processes. Further, a process thread may be considered a basic unit of processor utilization. A process may be composed of one or more process threads. Each operating system may have a different mechanism to handle the ownership of a process thread. For example, a mission-critical operating system includes a process thread ownership mechanism for assigning ownership of a process thread to an ownership agent. The ownership agent may obtain management control of the process thread after obtaining ownership of the process thread. For example, a piece of operating system logic or an ownership agent may request ownership of a process thread by declaring an "ownership event". The ownership agent may own (e.g., obtain management rights) the process thread until its control is relinquished. The ownership mechanism may avoid competition between various ownership agents to manage the ownership of the process thread.

[0010] Further, managing a multithreaded process may require granting management ownership of all process threads associated with the process to an ownership agent. When one or more process threads associated with a process may not be suspended, while another associated process thread is being managed by an ownership agent, the state of the latter may change. This may occur due to the fact that sibling process threads in a process may share memory. Such shared memory may be modified when at least one process thread may be free to run. In some cases, this may cause difficulties in the overall management of the process. Process thread collection may be used to place all sibling process threads within a process in a suspended state.

[0011] When a process thread meets certain ownership conditions, the process thread can then be suspended and its ownership is assigned to an ownership agent. However, some process threads may not be immediately available for ownership transfer. For example, a process thread may be in a wait condition, so the process thread will sleep for a specified amount of time or until a specific event occurs. In addition, a process thread with a wait event can be implemented in a privileged mode of an operating system. In other words, a process thread in a wait condition is considered to be running in a privileged mode (privileged system code) until the process thread is awakened by the return condition of the wait event. Before the return condition associated with the process thread occurs, the process thread may be in privileged mode all the time. In some cases, the return condition may not occur for a long time or may not occur at all, which may cause a deadlock condition. In some cases, a process thread may be in privileged mode indefinitely, resulting in an infinite delay in all management or other system processes of the process thread.

[0012] Process threads can be collected when exiting privileged mode because in privileged mode, some process threads may occupy some shared or critical resources of the system that have not been released. Therefore, when it can be considered safe to collect / suspend process threads, the collection of process threads is performed. To this end, certain management activities require suspending all sibling process threads associated with the main process thread (the subject of the ownership event). Each sibling process thread may be running in a different operating state or owned by an ownership agent working on it. In various examples, a "process thread" can be the basic unit of work or execution. A process can run one or more process threads. In a process with multiple process threads, the process thread that is the subject of ownership can be referred to as a "main process thread". With reference to the main process thread, all remaining process threads belonging to the same process can be referred to as "sibling process threads".

[0013] The process of collecting and suspending process threads becomes complicated because the collection of some process threads may be delayed, thereby affecting management activities. For example, multiple process threads may be in a wait condition and privileged mode, so the collection / suspension of process threads may not occur. Management control of such waiting processes / process threads may not be restored until such processes exit the privileged wait mode. Further, some operating systems may have interruptible and non-interruptible system calls. Non-interruptible system calls have difficulties in process and thread management, and may require an infinite amount of time to obtain ownership of the entire process for management. In some examples, no management operations are performed on the main process thread unless all peer process threads are collected and suspended. Since multiple process threads can be in such a wait condition, it may take longer to collect all process threads. In addition, ownership conditions associated with some process threads may not occur. For example, a process thread may wait for an input-output wait event that may not occur. For multiple peer process threads, this situation (e.g., waiting for a return condition) may result in an infinite delay condition, which may affect the ownership event and thus affect system performance. Therefore, it may be necessary to address the above shortcomings.

[0014] Therefore, various examples of handling process thread ownership in certain operating systems are disclosed herein. The techniques described herein can obtain ownership of a subject process thread and associated sibling threads in a shorter time by reducing / eliminating latency conditions. For example, certain process threads running under various operating conditions that do not allow for earlier collection and suspension can now be collected and suspended based on a set of ownership conditions.

[0015] In some examples, certain management processes need to collect and suspend process threads associated with a process thread group. The collection and suspension process includes the release and re-bidding of process threads. In some examples, based on a set of ownership conditions, a thread coordinator that implements the collection step and acts as an intermediate ownership agent is assigned ownership of all process threads of the process thread group. The present subject matter enables process threads that may be in privileged mode or waiting for events to be collected. Further, the collected process threads are suspended and ownership is assigned to the thread coordinator. The thread coordinator is configured to transfer ownership of the subject process thread to the ownership agent and raise an ownership event for it after the thread coordinator completes the collection process.

[0016] During the collection phase of process threads associated with a process thread group, the thread coordinator enables the process threads to pay attention to any wait events that occur. The examples described herein effectively utilize the collection phase to release certain process threads to pay attention to wait events that have occurred. In some examples, the process thread with the wait event can meet the ownership condition, whereby ownership is assigned to the thread coordinator. When other process threads are being collected, the process thread in which the wait event occurred is released. The thread coordinator again requests / re-bids for ownership of the released process thread. Other features and advantages of the present subject matter are discussed in the following description in conjunction with the accompanying drawings.

[0017] Throughout the drawings, the same reference numerals may denote similar but not necessarily identical elements. The index number "N" appended to some reference numerals may be understood to indicate only the plurality, and each reference numeral having such an index number "N" may not necessarily denote the same quantity.

[0018] The drawings are not necessarily drawn to scale, and certain parts and features may be schematically illustrated in the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings.

[0019] In the specification, the use of the terms "a", "an" or "the" is intended to include the plural forms as well, unless the context clearly indicates otherwise. Likewise, when used in the present disclosure, the terms "includes / including / comprises / comprising" or "have / having" specify the presence of stated elements, but do not exclude the presence or addition of other elements.

[0020] Figure 1An example computing device 100 for handling ownership of process threads according to the present subject matter is illustrated. The computing device 100 includes a processing element 105 coupled to a machine-readable storage medium 110 (hereinafter, for brevity, referred to as a "storage medium"). The storage medium 110 includes at least one operating system 115. The computing device 100 includes a set of instructions 120 stored in the storage medium 110 or stored in a storage disk 145. This set of instructions 120 can be associated with a program stored in the storage disk 145. In one example, the storage disk 145 can be part of the computing device 100. In other examples, the storage disk 145 can be arranged outside the computing device 100 and connected to the computing device 100 via a network 140. The network 140 can be a wired or wireless network. In some examples, the storage medium 110 can include one or more applications 135.

[0021] Further, the processing element 105 may include a single-core or multi-core processing element. The multi-core processing element may include multiple cores 105-1, 105-2, ..., 105-N. The processing element 105 may execute one or more processes (process thread groups) corresponding to the application 135. Further, each process may run one or more process threads. In one example, a process thread may be used as a basic execution unit within a process. Process threads belonging to a process may share resources associated with the process. For example, shared resources may include, but are not limited to, shared libraries, memory, and virtual address spaces.

[0022] Further, the operating system 115 includes a process thread scheduler 125 for scheduling the execution of process threads on the processing element 105. In some examples, the process thread scheduler 125 can be part of the kernel of the operating system 115. For example, the kernel can be capable of managing the operation of resources such as the processing element 105. In some other examples, the process thread scheduler 125 can be executed by the software and / or hardware layer of the computing device 100. The operating system 115 may include a thread coordinator 130, which acts as an intermediate ownership agent for handling ownership of process threads. In some examples, the set of instructions 120 may include instructions for handling (collecting / suspending) ownership of process threads by the thread coordinator 130 before transferring ownership to the ownership agent for which the ownership event is raised.

[0023] Figure 2 A schematic block diagram of an example computing device 200 according to the present subject matter is illustrated. The computing device 200 includes a processing element 205 and a machine-readable storage medium 210 (referred to as a 'storage medium' for brevity). The storage medium 210 may be of a non-transitory type and encoded with a set of executable instructions (e.g., instructions 215 to 240) for handling ownership of a process thread. Further, although Figure 2 The instructions are shown in order, but the instructions may be executed in any other order at any time and may be repeatedly executed by any suitable device or devices.

[0024] The processing element 205 can obtain, decode and execute instructions 215 to request ownership of the main process thread (ownership request) which can be made or claimed by a part of the operating system. Claiming an ownership event for the target process thread (i.e., the main process thread) can suspend the main process thread based on satisfying at least one of a set of predefined conditions. The main process thread can be part of a multi-threaded process, and the main process thread includes one or more sibling process threads. As used herein, all process threads associated with a process are collectively referred to as a "group of sibling process threads." In some examples, the request for ownership of the main process thread can be a bid made by claiming an ownership event. An "ownership event" can be associated with an ownership agent. In the case of more than one ownership event, the ownership agent associated with the highest priority ownership event can be considered for ownership.

[0025] The processing element 205 can obtain, decode and execute instructions 220 to obtain ownership of a group of process threads by the thread coordinator by executing one or more further instructions. The group of process threads includes a subject process thread and peer process threads associated with the subject process thread. In one example, one or more of the following instructions enable the acquisition of ownership of the group of process threads.

[0026] In response to determining that a particular process thread satisfies any one of the first set of ownership conditions, the processing element 205 may fetch, decode, and execute instructions 225 to assign ownership of the process thread to the thread coordinator. In some examples, the implementation code may check whether each process thread (in this set of process threads) satisfies any one of the first set of ownership conditions for assigning ownership. According to one example, the implementation code may be part of an operating system. The first set of ownership conditions may include a subset of wait conditions. The first set of ownership conditions includes non-privileged or wait events (hereinafter interchangeably referred to as "non-priv-OR-wait"). A subset of wait conditions includes the aforementioned "wait event", in which a process thread waits for an event to occur. In one example, a process thread waiting for an event may remain in a sleep state and be awakened when the wait event occurs.

[0027] In response to determining that at least one wait event associated with a process thread has occurred, the processing element 205 can obtain, decode and execute instructions 230 to release one or more process threads owned by the thread coordinator. In some examples, the thread coordinator can be notified of the occurrence of wait events corresponding to all process threads. In response to receiving the occurrence of (multiple) wait events or being notified of the occurrence of wait events, the thread coordinator can release such one or more process threads. For example, ownership of the process thread can be assigned to the thread coordinator based on any one of the first set of ownership conditions associated with the expected ownership event being satisfied, and the wait event that the process thread has been waiting for has not yet occurred.

[0028] And when the process thread is owned by the thread coordinator and the wait event that the process has been waiting for occurs. Then, the specific process thread is released to handle the wait event that has occurred. At the same time, when the acquisition of ownership of at least one process thread may be incomplete / pending, the specific process thread may be allowed to be released. Examples of the occurrence of the wait event may include the expiration of a timer associated with the wait event, the occurrence of a system event being waited for, etc. The thread coordinator bids or requests ownership of the released process thread. Therefore, during the collection phase of the process thread, the thread coordinator can perform the release and re-bid of one or more process threads.

[0029] The processing element 205 may fetch, decode, and execute instructions 235 to reassign ownership of one or more released process threads to the thread coordinator based on the condition that the one or more released process threads (each) satisfy any one of the first set of ownership conditions. The implementation code may check whether each released process thread satisfies any one of the first set of ownership conditions. In one example, after reacquiring ownership of the set of process threads including the released process thread, the thread coordinator may suspend further release of any process thread. At this point, the thread coordinator completes acquisition of ownership of the set of process threads.

[0030] When the process of acquiring ownership of all process threads in the set of process threads is completed, the processing element 205 can obtain, decode and execute instructions 240 to transfer ownership of the subject process thread from the thread coordinator to the ownership agent. The ownership agent has exclusive management rights / access rights to the subject process thread and works on it. In some examples, as part of the ownership transfer, the subject process thread can be queued to the work queue of the ownership agent.

[0031] In some examples, the thread coordinator holds the peer process threads and records any wait conditions or other wait events that occur corresponding to any peer process threads. However, the peer process threads will not be released until the management of the subject process threads is managed by the ownership agent. After the execution of the management action / management logic is completed for the subject process threads, the ownership agent releases the subject process threads to the thread coordinator. In some examples, when no other ownership events are pending, the thread coordinator can give up ownership of this group of process threads, and the process threads with any wait events that have occurred will continue to process the specific event.

[0032] In some other examples, the thread coordinator can notify the designated ownership agent of all current subject process threads to temporarily suspend management activities and let the thread coordinator release the (multiple) sibling threads associated with the wait event that has occurred. The thread coordinator re-bids the ownership of these released sibling threads so as to eventually collect them back and pass management control back to the designated ownership agent to continue the management activities of the ownership agent on the subject process threads.

[0033] FIG. 3A to FIG. 3H Multiple schematic diagrams are illustrated that illustrate handling process thread ownership according to the present subject matter. A bid / request for ownership of a subject process thread may be made by asserting an ownership event. The ownership event may correspond to a first ownership agent and the ownership event may be asserted by a portion of system code. In some examples, multiple ownership events may be asserted for a subject process thread, and the multiple ownership events correspond to different ownership agents. Such requests will be pending, and in any case, only one ownership agent may have exclusive control over the subject process thread. When multiple ownership events are raised by multiple ownership agents, the ownership event with the highest priority may be considered for ownership.

[0034] exist Figure 3A In the example shown, the subject process thread 320 may belong to a process thread group / process 305. Further, in some examples, the subject process thread 320 may include a peer process thread 315. All process threads associated with the process 305 are collectively referred to as a group of process threads 314. The group of process threads 314 may have one or more common resources 310. Further, certain ownership events may require a first ownership agent 360 ( Figure 3G 314) suspends all sibling process threads 315 of the subject process thread 320 before it can work on the subject process thread 320 or can maintain management ownership / control of the subject process thread 320. This group of process threads 314 are collected and suspended, and then ownership of the subject process thread 320 is assigned to the first ownership agent 360.

[0035] like Figure 3B As shown in the figure, each process thread can be operated in different states or owned and managed by various ownership agents. For the convenience of representation, this group of process threads 314 is classified into buckets 331 to 334 representing operating conditions. For example, bucket 331 represents privileged mode, bucket 332 represents waiting conditions, bucket 333 represents non-privileged mode, and bucket 334 represents immediate all / suspendable. For the sake of simplicity, the reference numerals of buckets can be used for corresponding patterns. If some process threads meet specific conditions, they can be listed in two or more buckets. In some examples, immediately all can include being in a dispatchable condition (not waiting for a wake-up event), non-privileged mode, without any lock (and no contention lock) and not owned by any ownership agent. The implementation code can check the operating conditions of each process thread associated with process 305.

[0036] exist Figure 3B In the example shown, process thread 316 is in privileged mode 331. Process thread 317 is in wait condition 332 and privileged mode 331. Process thread 318 is also in wait condition 332 but in non-privileged mode 333 (e.g., exited privileged mode). Process threads 319 and 320 are in immediately ownable 334. In the current example, both process threads, i.e., peer process thread 319 and subject process thread 320, are in immediately ownable and are listed in bucket 334. In one example, the first set of ownership conditions may include an immediately ownable mode. Figure 3C As illustrated in , based on determining that these dual process threads 319 and 320 meet any one of the first set of conditions, ownership of these processes is transferred to the thread coordinator 350. The dual process threads 319 and 320 collected by the thread coordinator 350 are suspended and not scheduled for execution. Further, a check can be performed to determine whether any process thread is in a non-privileged or wait condition / mode.

[0037] Furthermore, if Figure 3C As shown in FIG, both process threads 317 and 318 satisfy the non-privileged or waiting condition, that is, process thread 317 is in the non-privileged mode, and process thread 318 is in the waiting condition. Figure 3D As shown in FIG, the ownership of process threads 317 and 318 is assigned to thread coordinator 350. For ease of explanation, the checking of the immediately available condition and the non-privileged or waiting condition is illustrated separately. However, in one example, the first set of ownership conditions includes the immediately available condition, the non-privileged or waiting condition, etc., and can be checked at the same time.

[0038] In some examples, various conditions of a process thread may be evaluated or determined at different appropriate times depending on the operating environment of the process thread. For example, the process thread returns from privileged mode to user mode after completing execution of a privileged routine. The process thread may have exited privileged mode or is in non-privileged mode and meets any one of the first set of ownership conditions (e.g., non-privileged or waiting). Ownership of that particular thread is assigned to the thread coordinator 350.

[0039] In some examples, a process thread in a wait condition is considered to be waiting in privileged mode. An ownership event may require a process thread to be in non-privileged mode to transfer ownership. In the present subject matter, a first set of ownership conditions includes non-privileged or wait conditions that enable ownership of a process thread in non-privileged mode or with a wait condition to be acquired, except for process threads that run exclusively in privileged mode. For example, process threads 317 and 318 satisfy at least one condition in the first set of ownership conditions, and thread coordinator 350 acquires ownership of process threads 317 and 318. In addition, information related to the wait events that process threads 317 and 318 are waiting for is retained.

[0040] like Figure 3E As shown in the figure, in the process of collecting and suspending the peer process threads, if the waiting event corresponding to the process thread 317 has occurred. Based on the condition that the collection of one or more process threads in the process threads is pending (in the current example, the collection of the process thread 316 is pending), the thread coordinator 350 releases the process thread 317 to pay attention to the event that the process thread is waiting for. At the same time, the thread coordinator 350 re-bids the ownership of the released process thread 317 to obtain the ownership again (subject to predefined conditions).

[0041] like Figure 3F As illustrated in , the process thread 316 may have satisfied any one of the first set of ownership conditions, whereby ownership of the process thread 316 is assigned to the thread coordinator 350. For example, the process thread 316 may have exited the privileged mode and is running in the user mode or the non-privileged mode. In one example, the process thread 316 may be waiting for an input / output operation to complete to exit the privileged mode. Further, the implementation code checks whether the released process thread 317 satisfies any one of the first set of ownership conditions. Based on the released process thread 317 satisfying any one of the first set of ownership conditions, the thread coordinator 350 reacquires ownership of the released process thread 317.

[0042] like Figure 3GAs illustrated in , after acquiring ownership of the set of process threads 314, the thread coordinator 350 suspends the release of any process thread even when the associated wait event has occurred. The thread coordinator 350 transfers or assigns the ownership of the subject process thread 320 to the first ownership agent 360 corresponding to the request or bid ownership event. During the time when the first ownership agent 360 works on the subject process thread 320, the thread coordinator retains the ownership of the sibling process threads 316 to 319.

[0043] In addition, in some examples, by design (based on one or more design conditions), the thread coordinator 350 can be notified of the occurrence of a wait event for one of the sibling process threads 316 to 319 while the first ownership agent 360 is working on the subject process thread 320. The first ownership agent 360 can temporarily suspend its management activities for the subject process thread 320 and transfer the ownership of the subject process thread 320 back to the thread coordinator 350. The thread coordinator 350 can then release those sibling process threads associated with any wait events that have occurred and re-bid the ownership of these released sibling process threads. These released sibling process threads can continue to process the events that have occurred for which they have been waiting. Once these re-bid sibling process threads have been re-collected by the thread coordinator 350, the thread coordinator 350 transfers the ownership of the subject process thread 320 to the designated ownership agent 360 to continue the management activities of the ownership agent for the subject process thread 320. In some examples, the current condition is selectively provided based on one or more design conditions and a time limit target for how long the wait event that occurs can be watched.

[0044] Furthermore, if Figure 3H As shown, once the first ownership agent has processed the subject process thread 320, the subject process thread is released to the thread coordinator 350. The thread coordinator 350 can check whether any ownership event has been asserted to request ownership of any process thread outside the group of process threads 314. If the ownership event is available for any process thread, the specific process thread for which the request / ownership event is made can be regarded as the subject process thread and the remaining process threads are regarded as sibling process threads. The thread coordinator assigns ownership of the new subject process thread to the second ownership agent associated with the ownership event of the new subject process thread and holds the sibling process thread. However, when there is no ownership request pending corresponding to any ownership agent, the thread coordinator relinquishes ownership of all process threads in the group of process threads.

[0045] Figure 4A and 4BA flow chart is illustrated that illustrates an example method 400 for handling ownership of process threads in more detail. A computing device begins by starting an initialization process during startup. The initialization process may be referred to as a daemon process. The computing device may execute one or more general and / or specific programs or applications. In certain management processes, a system library or system process may need to collect and suspend a set of process threads before the ownership of the subject process threads can be transferred to an ownership agent. The flow chart illustrates an example method for collecting and suspending this set of process threads with improved ownership handling.

[0046] At 405, a request for ownership of the subject process thread may be made by asserting an ownership event associated with an ownership agent. The current instance of the ownership agent is referred to as the "first ownership agent". In some examples, ownership may be bid by more than one ownership agent (ownership event). In some examples, a portion of the system code may request / bid for an ownership event. Ownership events may be based on conditions such as process thread dispatchable, lock-free, in non-privileged mode, relative priority of events, registered agents (default handlers for given events), etc. In this case, based on a set of event priorities, ownership may be considered to be assigned to the ownership agent with the highest event priority. In some examples, implementation code running on a processing element may at least partially handle ownership events and the assignment of ownership. In one example, a thread coordinator may be an intermediate ownership agent or a management agent. The thread coordinator and implementation code may be part of an operating system of a computing device. For example, the implementation code may be a library code, such as Millicode that may implement a low-level API of a processing element. In some examples, ownership of this set of process threads is assigned to the thread coordinator by the implementation code. Further, in order to collect this set of process threads, the thread coordinator bids / requests ownership of the process threads.

[0047] At 410, a check may be performed to determine whether the subject process thread includes any sibling process threads. For example, in the case of a multithreaded process, it is determined that the subject process thread includes sibling process threads. As previously described, some management processes need to suspend sibling process threads so that the management process is executed without any sibling process thread interruption. For example, the group of process threads associated with the process may access a group of common resources, such as data, files, etc. Therefore, the sibling process threads may access these groups of common resources and thus interrupt the management process without being collected and suspended.

[0048] At 415, the ownership of the group of process threads is obtained between 420 and 455. For example, at 420, each process thread is checked to see if it satisfies any of the first set of ownership conditions. In other words, a check is performed to determine if any process thread satisfies any of the first set of ownership conditions. A process thread in a waiting condition (privileged / non-privileged mode) or running in a non-privileged mode may satisfy the ownership condition. In one example, a process thread satisfies the ownership condition when it exits the privileged mode and runs in a user mode / non-privileged mode. In a further example, a process thread in an immediately available mode / condition may also satisfy the ownership condition. A process thread that satisfies any of the first set of ownership conditions is eligible for collection and suspension. Further, one or more process threads may not satisfy any of the first set of ownership conditions. In other examples, based on the determination at 410, the target process thread is single-threaded. In this case, the ownership of the target process thread (i.e., the subject process thread) may be granted to a designated agent directly or through a thread coordinator.

[0049] At 425, according to one example, implementation code running on the processing element may wait for one or more selected process threads to satisfy any one of a first set of ownership conditions. However, based on the condition that the selected process thread satisfies any one of the first set of ownership conditions at 420, ownership of the selected process thread is assigned to the thread coordinator at 430. In a further example, the first set of ownership conditions includes, but is not limited to, the process thread is running in a non-privileged mode, the process thread is stoppable, the process thread is in a process thread lifecycle that allows the process thread to be owned, the subject process thread reaches a point where it is considered terminated, and a Portable Operating System Interface (POSIX) signal is temporarily disabled.

[0050] During the collection and suspension of process threads, at 435, a check is performed to determine whether any wait conditions associated with the process threads available to the thread coordinator have occurred. In other words, whether a wait event associated with the collected process threads has occurred in the process of collecting the process threads. The thread coordinator is notified about the wait event that has occurred. However, at 435, if any wait conditions associated with the process threads have not occurred, then in some examples, the system may continue to check whether any pending process threads meet any of the first set of ownership conditions to grant ownership to the thread coordinator. However, at 435, if a wait condition associated with all process threads of the thread coordinator has occurred, then simultaneously or subsequently, at 440, a check is performed to determine whether the acquisition of ownership of this set of process threads has been completed.

[0051] In some examples, the check at 435 is performed in one or more of the following examples. All process threads of the thread coordinator can be in a running state or a ready-to-run state. The ready-to-run state can mean that the process thread has no execution time of the processor, and it can run after obtaining execution time. The process thread can run until the state of the process thread changes. During this state change, a check is performed to determine whether there are any wait conditions associated with the process thread. For example, the process thread may have completed the execution of privileged system code and returned to its user code. During this state change, a check can be performed to see if a particular process thread has any pending ownership events, such as non-privileged mode in the current example. In this case, the particular process can be released.

[0052] In another example, the process thread may call a privileged system wait function. The process thread may be put to sleep to wait for certain wait events. In this case, according to an example, a check may be performed to determine if any ownership bids are pending with non-privileged or wait conditions.

[0053] Based on the condition that the wait event associated with the specific process thread has occurred and the ownership of the group of process threads is not completed at 440, at 445, the specific process thread is released from the thread coordinator. Further, the thread coordinator re-bids or requests ownership for all released process threads. The released process thread pays attention to the event it is waiting for. Further, in some examples, the release of the process thread can be handled by the implementation code and the process thread can return to the operating state it was in before the ownership transfer. For example, the wait event information associated with the process thread is also retained. When released, the process thread can pay attention to the event that has occurred. In some examples, a specific process thread that is in privileged mode and is not currently in wait mode can spend a short duration to complete execution and exit privileged mode or can enter another wait condition. When entering another wait condition, the specific released process thread can meet the non-privileged or wait condition in the first group of ownership conditions.

[0054] In some examples, when ownership of a process thread is acquired, the process thread is queued in an ownership queue of a thread coordinator. Further, when a wait event corresponding to the process thread has occurred, the process thread is then requeued in an ownership queue of the thread coordinator. The thread coordinator identifies a specific process thread that it already owns. The thread coordinator can determine that a specific process thread is in a non-privileged or wait condition and that an associated wait condition has occurred. The thread coordinator can release the process thread based on a condition that the process of acquiring (collecting and suspending) one or more process threads is still pending. For example, the occurrence of a wait event can include the expiration of a wait timer or the occurrence of a system event being waited for. The thread coordinator bids or requests ownership of the released process thread, and this action can be referred to as re-bidding or re-acquiring. Further, the process thread returns to the operating state in which these process threads were before the thread coordinator acquired ownership. One or more released process threads pay attention to the occurrence of the corresponding associated wait events they are waiting for.

[0055] At 450, a check is performed to see if any released process thread satisfies any of the first set of ownership conditions to assign ownership of a particular process thread to the thread coordinator. In some examples, the check may be performed upon observing a change in state of the process thread. The change in state may include exiting privileged system code, processing a wait event, the process thread calling a privileged system wait function, etc. In one example, the released process thread may enter another wait condition again or may satisfy any other condition in the first set of ownership conditions. For example, the released process thread satisfies a non-privileged or wait condition, thereby enabling ownership to be assigned to the thread coordinator.

[0056] At 455, ownership of the particular released process thread is reassigned to the thread coordinator based on the condition that the released process thread satisfies any one of the first set of ownership conditions. In one example, the particular process thread may not have any other waiting events. In another example, the particular process thread may be suspended but may be waiting for an event to occur. Further, a check may be performed to determine whether any of the process threads (pending for assignment to the thread coordinator) satisfies any one of the first set of ownership conditions.

[0057] Based on the condition that the acquisition of ownership of the set of process threads is complete (at 440), at 460, a transfer of ownership of the subject process thread to the first ownership agent is performed. The release of process threads (and re-tendering of ownership) is performed until the collection of ownership of any process thread from the set of process threads is pending. After the collection / acquisition of ownership of the set of process threads is completed, the thread coordinator suspends any further release of process threads. After the ownership of the subject process thread is transferred to the first ownership agent, the thread coordinator retains ownership of the sibling process threads.

[0058] After the work on the subject process thread is completed, the first ownership agent relinquishes ownership of the subject process thread (ownership release), and ownership of the subject process thread is assigned to the thread coordinator. The implementation code may check any pending ownership events for any process thread in the set of threads held by the thread coordinator. Based on priority, pending ownership events may be considered. For example, a pending ownership event may be associated with a second ownership agent. Ownership of the new subject process thread (corresponding to the pending ownership event) is assigned to the second ownership agent. The thread coordinator holds ownership of the peer process thread until the second ownership agent works on the new subject process thread. However, when the first ownership agent relinquishes ownership of the subject process thread and no further pending ownership events are available, the thread coordinator relinquishes ownership of the set of process threads.

[0059] In some examples, a predefined class of management processes may include a debug session for a process / process thread group. In such a predefined class of management processes, the thread coordinator may initiate acquisition of ownership of a process thread, but suspend release of the process thread (during the collection process) even when an associated wait event occurs. For example, a debug session may require that the process thread be in the same state without any changes. In this case, release and re-bidding / reassignment of the process thread is suspended. In one example, the operation code may suspend release of one or more process threads based on determining that the current management process belongs to a predefined class of management processes.

[0060] In a further example, a portion / segment of operating system code may be marked as critical. Method 400 may include suspending at least one of the first set of conditions. In a preferred example, a non-privileged or wait condition may be suspended while the target process thread is executing such a code segment marked as critical. In this case, ownership of the target process thread is not assigned to the thread coordinator. In some examples, suspending the non-privileged or wait condition may prevent any potential deadlock. For example, if such a segment of code acquires a high-level scarce resource, the resource will be released at the end of the segment of code, and such resource may be required between the time when the designated agent is granted ownership of the target process thread and the time when the designated agent finishes processing the target process thread. It may be ensured that the thread coordinator does not collect the process thread when executing such a marked code segment.

[0061] In some examples, method 400 may be implemented by (multiple) processing elements through any suitable hardware, non-transitory machine-readable storage media, or a combination thereof. In an example, method 400 may be performed by machine-readable instructions, which include instructions stored on a storage medium and executable by a processing element such as a hardware processor of computing device 100, 200. In some examples, processing element 105, 205 may be one or more central processing units (CPUs), one or more semiconductor-based microprocessors, one or more graphics processing units (GPUs), other hardware devices suitable for obtaining and executing instructions stored in a machine-readable storage medium, or a combination thereof. Processing element 105, 205 may be a physical device. In addition, in one example, processing element 105, 205 may include multiple cores on a chip, including multiple cores on multiple chips, multiple cores on multiple devices (for example, if computing device 100 includes multiple node devices), or a combination thereof. In some examples, the hardware processor may be part of a mission-critical system. A mission-critical system may be a fault-tolerant, always-online, etc. system deployed for a mission-critical solution.

[0062] Processing elements 105, 205 may fetch, decode and execute instructions 215 to 240 or 405 to 460 to implement the handling of ownership of process threads. As an alternative or supplement to fetching and executing instructions, processing elements 105, 205 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or a combination of multiple electronic components thereof including functions for executing instructions. A machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device containing or storing executable instructions. Thus, a machine-readable storage medium may be, for example, a random access memory (RAM), a non-volatile RAM (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a storage device, an optical disk, or the like. In some examples, a machine-readable storage medium may be a non-transitory storage medium, wherein the term "non-transitory" does not encompass transient propagation signals.

[0063] The computing device also includes a main memory coupled to the bus for storing information and instructions to be executed by the processing element, such as a random access memory (RAM), a cache and / or other dynamic storage devices. The main memory can also be used to store temporary variables or other intermediate information during the processing element execution of the instruction. Such instructions, when stored in a storage medium accessible to the processing element, make the computing device a special-purpose machine that is customized to perform the operation specified in the instruction. The computing device further includes a read-only memory (ROM) or other static storage device coupled to the bus for storing static information and instructions. Storage devices such as disks, optical disks or universal serial bus (USB) thumb drives (flash drives) are provided and to the bus for storing information and instructions.

[0064] By way of example, the above elements may include components (such as software components, object-oriented software components, class components, and task components), processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0065] Generally, the words "element", "system", "device", etc. as used herein may refer to logic implemented in hardware or firmware, or to a software instruction set written in a programming language such as Java, C or C++, which may have entry points and exit points. Software components may be compiled and linked to executable programs, installed in dynamic link libraries, or may be written in interpretive programming languages ​​such as BASIC, Perl, or Python. It should be understood that software components may be called from other components or from themselves, and / or may be called in response to detected events or interruptions. Software components for execution on a computing device may be provided in a machine-readable medium, such as a compact disk, a digital video disk, a flash drive, a disk, or any other tangible medium, or may be provided as a digital download (and may be stored originally in a compressed format or an installable format that requires installation, decompression or decryption before execution). Such software code may be stored in part or in whole on a memory device that executes a computing device for execution by the computing device. Software instructions may be embedded in firmware, such as an erasable programmable read-only memory (EPROM). It will be further understood that hardware components may include connected logic units such as gates and flip-flops, and / or may include programmable units such as programmable gate arrays or processors.

[0066] According to one example, the techniques herein are performed by a computing device in response to (multiple) processors executing one or more sequences of one or more instructions contained in a main memory. Such instructions may be read into the main memory from another storage medium (such as a storage device). Execution of the sequence of instructions contained in the main memory causes (multiple) processors to perform the process steps described herein. In alternative examples, hard-wired circuits may be used in place of or in combination with software instructions.

[0067] Although specific examples have been shown and described above, various changes in form and detail may be made. Certain features described with respect to one example and / or method may be associated with other examples. In other words, the flow chart, method, feature, component and / or characteristic described with respect to one example may be used for other examples. In addition, it should be understood that the systems and methods described herein may include various combinations and / or sub-combinations of components and / or features of the different examples described. Therefore, features described with reference to one or more examples may be combined with other examples described herein.

Claims

1. A method comprising: Receiving, by the processing element, an ownership request of the subject process thread through an ownership event corresponding to the first ownership agent; The processing element acquires ownership of a group of process threads through a thread coordinator, wherein the group of process threads includes the main process thread and a group of peer process threads associated with the main process thread, wherein the acquisition includes: determining, by the processing element, that each of one or more process threads in the set of process threads satisfies any one of a first set of ownership conditions, wherein the first set of ownership conditions includes a subset of wait conditions, causing the processing element to assign ownership of the one or more process threads to the thread coordinator; determining, by the processing element, that at least one wait condition associated with a process thread in the subset of wait conditions has occurred and a process that acquires ownership of at least one process thread is not completed, causing the processing element to release one or more process threads from the thread coordinator; and determining, by the processing element, that one or more released process threads satisfy any one of the first set of ownership conditions, so that the processing element reassigns ownership of the one or more released process threads to the thread coordinator; and When the process of acquiring ownership of the set of process threads is completed, ownership of the subject process threads is transferred from the thread coordinator to the first ownership agent by the processing element.

2. The method of claim 1, wherein: The first set of ownership conditions includes: the availability of the process thread is in an immediate ownership condition, the process thread exits the privileged mode, and the process thread waits for an event to occur.

3. The method of claim 1, further comprising: Ownership of the set of sibling process threads is retained by the processing element through the thread coordinator during the time the first ownership agent maintains administrative ownership of the subject process thread.

4. The method of claim 1, further comprising: When the first ownership agent releases the ownership of the subject process thread, the ownership of the subject process thread is assigned by the processing element to the thread coordinator.

5. The method of claim 4, further comprising: retaining, by the processing element through the thread coordinator, ownership of the set of process threads; as well as A determination is made, by the processing element, whether one or more requests for any selected process thread from the set of process threads are made via ownership events corresponding to one or more ownership agents.

6. The method of claim 5, further comprising: A determination by the processing element that an ownership event for the selected process thread corresponds to a second ownership agent causes the processing element to assign ownership of the selected process thread to the second ownership agent.

7. The method of claim 5, further comprising: Ownership of the selected process thread is assigned, by the processing element, to a second ownership agent having a highest priority ownership event of the one or more ownership events proposed by the one or more ownership agents for the selected process thread.

8. The method of claim 5, further comprising: A determination by the processing element that no ownership event is pending for any process thread in the set of process threads causes the processing element to release ownership of the set of process threads from the thread coordinator.

9. The method of claim 1, wherein: Determining, by the processing element, that the at least one wait condition associated with the process thread has occurred includes: The process thread is requeued by the processing element into the work queue of the thread coordinator.

10. The method of claim 9, further comprising: A determination by the processing element that one or more process threads are requeued into a work queue of the thread coordinator causes the processing element to release the one or more process threads from the thread coordinator.

11. A computing device comprising: Hardware-based processing elements; as well as A machine-readable storage medium storing instructions, which when executed by the hardware-based processing element cause the hardware-based processing element to perform the following operations: receiving an ownership request of a subject process thread through an ownership event corresponding to a first ownership agent; Acquiring ownership of a group of process threads through a thread coordinator, wherein the group of process threads includes the subject process thread and a group of sibling process threads associated with the subject process thread, wherein acquiring includes performing the following operations by the hardware-based processing element: determining that one or more process threads in the set of process threads satisfy any one of a first set of ownership conditions, wherein the first set of ownership conditions includes a subset of wait conditions, causing the hardware-based processing element to assign ownership of the one or more process threads to the thread coordinator; determining that at least one wait condition of the subset of wait conditions associated with each of the process threads has occurred and a process to acquire ownership of at least one of the set of process threads is not completed, causing the hardware-based processing element to release one or more process threads from the thread coordinator; and determining that one or more released process threads satisfy any one of the first set of ownership conditions, causing the hardware-based processing element to reassign ownership of the one or more released process threads to the thread coordinator; and When the process of acquiring ownership of the set of process threads is completed, ownership of the subject process threads is transferred from the thread coordinator to the first ownership agent.

12. The computing device of claim 11, wherein: Releasing one or more process threads from the thread coordinator includes performing the following operations by the hardware-based processing element: The one or more process threads are returned to an operating state before the thread coordinator acquired ownership, and the one or more process threads attend to respective associated wait events that they are waiting for to occur.

13. The computing device of claim 11, further comprising: an operating system including implementation code running on the hardware-based processing element, wherein The implementation code checks whether any process thread in the set of process threads satisfies any one of the first set of ownership conditions.

14. The computing device of claim 13, wherein: The first set of ownership conditions further includes at least one of the following: the process thread is in a dispatchable condition, the process thread does not have any locks, the process thread is not owned by any ownership agent, the process thread is in a non-privileged mode, and the process thread waits for an event to occur.

15. A non-transitory machine-readable storage medium comprising instructions executable by a processing element of a device to perform the following operations: receiving a request for ownership of a subject process thread via an ownership event associated with a first ownership agent; Take ownership of a set of process threads through the thread coordinator, where The group of process threads includes the subject process thread and a group of sibling process threads associated with the subject process thread, wherein the instructions for obtaining include instructions executable by the processing element for performing the following operations: determining that one or more process threads in the set of process threads satisfy any one of a first set of ownership conditions, wherein the first set of ownership conditions includes a subset of wait conditions, causing the processing element to assign ownership of the one or more process threads to the thread coordinator; determining that at least one wait condition of the subset of wait conditions associated with each of the one or more process threads has occurred and a process to acquire ownership of at least one process thread of the set of process threads is not completed, causing the processing element to release the one or more process threads from the thread coordinator; and determining that one or more released process threads satisfy any one of the first set of ownership conditions, so that the processing element releases the one or more process threads from the thread coordinator; and When the process of acquiring ownership of the set of process threads is completed, ownership of the subject process threads is transferred from the thread coordinator to the first ownership agent.

16. The non-transitory machine-readable storage medium of claim 15, wherein: A subset of the wait conditions includes waiting for a timer and waiting for a system event to occur.

17. The non-transitory machine-readable storage medium of claim 15, wherein: The instructions for receiving the request for ownership of a subject process thread via the ownership event include instructions for: When multiple ownership events corresponding to multiple ownership agents are asserted for a selected process thread, an ownership event having a highest priority is selected.

18. The non-transitory machine-readable storage medium of claim 15, wherein: The instructions for assigning ownership of one or more process threads in the set of process threads to the thread coordinator include instructions for: The process thread is queued into the work queue of the thread coordinator.

19. The non-transitory machine-readable storage medium of claim 15, wherein: The instructions for releasing one or more process threads from the thread coordinator further include instructions for: Based on determining that the current management process belongs to a predefined category of management processes, release of one or more process threads is suspended.

20. The non-transitory machine-readable storage medium of claim 15, further comprising instructions for: Determining, based on one or more design conditions, that at least one wait condition in the subset of wait conditions associated with each of the one or more process threads has occurred, causing instructions to release the one or more process threads from the thread coordinator and release the subject process thread to the thread coordinator; and Determine that each of the one or more released process threads satisfies any one of the first set of ownership conditions, so that the instruction reassigns ownership of the one or more released process threads to the thread coordinator and reassigns ownership of the subject process thread to the first ownership agent.

Images