Environmental collaboration cancellation with green threads

Abstract

The device may queue the threads for execution by the thread pool, including configuring the environmental context with the cancel token. Based on the call of the thread to the synchronization method, the device may determine that the thread uses a green thread model and identify a cancel token from the environmental context. Based on the thread using the green thread model, the device may invoke an asynchronous method that performs tasks of the synchronization method using asynchronous operations, including passing a cancel token to the asynchronous method. Based on the state change identifying the cancel token, the device may terminate the asynchronous operation.

Description

BACKGROUND

[0001] In computer science, asynchronous programming is a way for a context (e.g., a main thread) to initiate an asynchronous operation (e.g., by calling a method) without blocking to wait for the operation to complete. One application of asynchronous programming is to avoid tying up limited computing resources. For example, in a computing system, creating, operating, and destroying each thread incurs an overhead (e.g., storage resources, processing resources). To mitigate these overheads and to prevent overconsumption of computing resources (e.g., to avoid creating an unlimited number of threads, to avoid creating and destroying a thread for each requested operation), an operating system creates a thread pool with a finite number of threads that can be used to perform work on behalf of other threads, such as input / output operations. Asynchronous techniques enable multiple operations to be assigned to each thread in the thread pool, thereby enabling multiplexed operations among the threads of the thread pool.

[0002] One model used in many modern programming languages to represent asynchronous operations is to associate a "callback" with a task. A callback is a method that is called after a task is completed. One way to register a callback is continuation passing, in which a callback is passed to a method, and the method calls the callback after it completes its work. The use of callbacks and continuation passing allows a series of asynchronous operations to be chained together in a way that ensures they are executed in the correct order. Callbacks can be added explicitly by a programmer. For example, in the.NET Framework (Microsoft Corporation, Redmond, Washington), 'asynchronous' methods allow a program to perform non-blocking operations (such as network or disk access) without blocking a thread that initiates the operation. When an async method is called, it returns a Task object that represents the operation in progress. The method then continues to execute in the background, and the calling code can proceed to other tasks. Once the async method task is complete, it returns a result or throws an exception. The calling code can use the 'await' keyword to pause execution until the operation is complete and the result is available. Additionally, or alternatively, a callback can be added via a compiler transformation.

[0003] Sometimes, it can be desirable to cancel an asynchronous task after it has been initiated (e.g., to stop long-running operations such as network requests or file transfers when they are no longer needed). One mechanism for canceling an asynchronous task is to use a cancellation token, which provides a way to notify an operation that is running that it should be canceled. A source context creates a cancellation token and passes the token to the asynchronous operation(s) (e.g., as a parameter to an async method). Each asynchronous operation can in turn pass the received cancellation token (alone or in combination with other tokens) to further asynchronous operation(s). To request cancellation, the source context cancels the token, which effectively propagates the cancellation signal to any operations listening for the cancellation signal. For example, the operations can periodically poll the cancellation token to see if cancellation has been requested, or register a callback that is triggered if cancellation is requested, and exit early (e.g., call the registered callback method) when cancellation is requested.

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided only to illustrate one example technology area where some embodiments described herein can be practiced. SUMMARY

[0005] In some aspects, the technology described herein relates to methods, systems, and computer program products including queuing a thread for execution by a thread pool, including configuring an ambient context with a cancellation token; determining, based on a call by the thread to a synchronous method, that the thread uses a green thread model; and identifying the cancellation token from the ambient context; invoking, based on the thread using the green thread model, an asynchronous method that uses an asynchronous operation to perform a task of the synchronous method, including passing the cancellation token to the asynchronous method; and terminating the asynchronous operation based on identifying a state change of the cancellation token.

[0006] In some aspects, the technology described herein relates to methods, systems, and computer program products including queuing a thread for execution by a thread pool; determining, based on a call by the thread to a synchronous method, that the thread does not use a green thread model; and performing, based on the thread not using the green thread model, a task of the synchronous method.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter. BRIEF DESCRIPTION OF DRAWINGS

[0008] To describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of certain embodiments will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein and are not therefore to be considered to be limiting of their scope, the systems and methods will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0009] Figure 1 An example of a computer architecture that facilitates environment- coordinated cancellation with green threads is shown.

[0010] Figure 2 An example of an asynchronous method call is shown.

[0011] Figure 3 An example of a synchronous method call is shown, where the synchronous method continues synchronously based on an environment context.

[0012] Figure 4 An example of a synchronous method call is shown, where the synchronous method invokes an asynchronous implementation based on an environment context.

[0013] Figure 5 A flow diagram of an example of a method for converting a synchronous operation to an asynchronous operation with an environment context when the synchronous operation is executed on a green thread is shown. DETAILED DESCRIPTION

[0014] In this specification and in the claims, the term "callback model" refers to any programming model that uses callbacks and continuations to explicitly specify the asynchrony of thread operations. In this specification and in the claims, the term "asynchronous thread" refers to any thread that implements asynchrony using the callback model. In this specification and in the claims, the term "green thread model" refers to any programming model that implicitly asynchronizes thread operations (e.g., in which the runtime converts synchronous calls to asynchronous calls). In this specification and in the claims, the term "green thread" refers to any thread that relies on the green thread model to implement asynchrony.

[0015] Some languages, such as the GO programming language (GOOGLE LLC, Mountain View, CA), include the concept of green (or virtual) threads. A green thread is a programming abstraction that allows multiple virtualized threads to exist within a single operating system (OS) thread. In a green thread model, developers write code using synchronous calls. The language runtime then intercepts these synchronous calls and converts them to asynchronous calls. For example, this involves the runtime determining that a green thread is initiating a synchronous operation (e.g., by calling a synchronous system call for an input / output (I / O) operation), the runtime saving the state of the green thread (e.g., by copying the stack state to another location), and the runtime initiating the asynchronous operation on behalf of the green thread (e.g., by calling an asynchronous system call for the I / O operation). This allows the associated OS thread to continue execution while the green thread is blocked. Later, when the asynchronous work initiated on behalf of the green thread completes and the OS thread is available, the runtime restores the saved state of the green thread onto the OS thread and resumes execution of the green thread. In effect, because the synchronous operation has been converted to an asynchronous operation, the green thread will block on completion of the synchronous operation without blocking the OS thread associated with the thread.

[0016] At least some embodiments described herein utilize the green thread model to compose a callback model, such as the asynchronous programming model used by the.NET framework. For example, embodiments enable asynchronous threads and green threads to coexist. In this case, there is a challenge to cancel pending operations on a green thread. For example, there is a challenge of how an asynchronous thread can signal to a green thread that an asynchronous operation (e.g., an asynchronous operation that the language runtime has converted from a synchronous operation) of the green thread should be cancelled. This is because the green thread only makes synchronous calls and thus does not use an explicit cancellation model, so a synchronous thread cannot pass a cancellation token to the green thread.

[0017] To address these challenges, at least some embodiments described herein extend the use of cancellation tokens (such as those supported by the.NET Framework) to encompass implicitly asynchronous threads (e.g., green threads) in addition to explicitly asynchronous threads. For example, some embodiments described herein extend the application programming interface (API) for starting or queuing a green thread to take a cancellation token as a parameter. In these embodiments, the cancellation token is stored in the green thread's ambient context (e.g., the overall state associated with the green thread) in a manner that enables the token to be accessed by any code running on the green thread. These embodiments also implant detection in synchronization operations to use the ambient context to determine whether the synchronization operation is executing on a green thread. If the synchronization operation determines that it is not executing on a green thread, the operation proceeds using its synchronization implementation. If the synchronization operation determines that it is executing on a green thread, the operation delegates to a corresponding asynchronous operation, passing the cancellation token stored in the green thread's ambient context to the asynchronous operation. In this way, developers can write synchronization code using existing synchronization methods without explicitly handling the effects of cancellation in the programming model. The synchronization code can then be used with an ambient token that enables cancellation of all involved asynchronous operations.

[0018] Accordingly, embodiments described herein combine the callback model and the green thread model while providing a mechanism for signaling to asynchronous operations (e.g., that have been delegated by a synchronization operation of a green thread) that the operation has been canceled. This enables the combination of explicitly specified asynchronous operations (e.g., using the callback model) with implicitly specified asynchronous operations (e.g., using the green thread model) and supports cancellation of these combined operations. Additionally, by implanting detection in synchronization operations to use the ambient context of the thread to determine whether they are executing on a green thread and delegate as needed, embodiments described herein express cancellation using APIs that do not have any cancellation concept in their signature. This also avoids the need to extend these APIs, which are in the thousands in modern languages such as the.NET Framework.

[0019] Figure 1 An example of a computer architecture that facilitates ambient cooperative cancellation with green threads is shown. As shown, computer architecture 100 includes computer system 101, which includes processor system 102 (e.g., a single processor or multiple processors), memory 103 (e.g., system or main memory), and storage media 104 (e.g., a single computer-readable storage medium, or multiple computer-readable storage media), all interconnected over bus 106. Computer system 101 can also include network interface 105 (e.g., one or more network interface cards) for interconnecting with one or more other computer systems via a network.

[0020] Storage medium 104 is illustrated as storing computer-executable instructions implementing at least an OS 109 (e.g., WINDOWS, LINUX, MAC OS, etc.), a language runtime 110 (e.g.,.NET, JAVA, GO, PYTHON, etc.), and an application 111. In Figure 1 The OS 109 includes, among other things, system calls 113 that the OS 109 makes available to the application 111 via the language runtime 110. While Figure 1 The OS 109 and the language runtime 110 are illustrated as separate, in embodiments the language runtime 110 is implemented at least in part by the OS 109. In embodiments, the application 111 includes computer-executable code configured to utilize APIs provided by the language runtime 110.

[0021] The processor system 102 is illustrated as executing a thread pool 112 that includes a number of threads (e.g., thread 112a through thread 112n). These threads perform operations on behalf of software executing at the computer system 101, including the application 111. In some embodiments, the thread pool 112 is managed directly by the OS 109. In other embodiments, the thread pool 112 is managed by the language runtime 110. In one example, the thread pool 112 is a pool of threads (e.g., “worker” threads) that multiplex operations (e.g., I / O operations to access data on the storage medium 104, or to access the network interface 105) from a queue, including operations requested by the application 111. In embodiments, the operations are created via system calls 113. For example, a thread executing at the thread pool 112 can initiate a synchronous read I / O operation by calling a ‘Read’ method within the system calls 113, and a thread executing at the thread pool 112 can initiate an asynchronous read I / O operation by calling a ‘ReadAsync’ method within the system calls 113.

[0022] In embodiments described herein, the language runtime 110 supports explicitly specified asynchronous operations (e.g., a callback model). This means that the language runtime 110 enables the application 111 to cause work to be queued at the thread pool 112 via a call to an asynchronous method 119. This includes enabling the application 111 to pass a cancellation token to the asynchronous method 119 (e.g., for signaling the cancellation of an asynchronous operation initiated by the asynchronous method 119). In some embodiments, the asynchronous method 119 is part of the language runtime 110 that utilizes the system calls 113 to perform the asynchronous work (e.g., by calling an asynchronous version of a system call, such as the ReadAsync method). In other embodiments, the asynchronous method 119 is itself one of the system calls 113.

[0023] For example,Figure 2 An example 200 of an asynchronous method call is shown, in which an application thread 201 (e.g., application 111) makes an asynchronous method call 205 to an asynchronous method 210. This results in the creation (e.g., by the language runtime 110) of an asynchronous thread 207 for execution at a thread pool (e.g., thread pool 112). In example 200, the application thread 201 explicitly creates a cancellation token 206 (e.g., creates cancellation token 204) and passes this cancellation token 206 as part of the asynchronous method call 205. Thus, at the asynchronous thread 207, the asynchronous method 210 has direct access to the cancellation token 206. This means that the application thread 201 can cancel the asynchronous operation being performed by the asynchronous thread 207 based on interaction with the cancellation token 206 (e.g., by calling the ‘Cancel’ method of the object corresponding to the cancellation token 206). Notably, in Figure 2 In example 200, the application thread 201 has a thread context 202 that indicates the thread type 203 of the application thread 201, and the asynchronous thread 207 has a thread context 208 that indicates the thread type 209 of the asynchronous thread 207. The thread contexts 202 and 208 are examples of “ambient” contexts, in that they are accessible to any code executing on the thread (e.g., code executing at the application thread 201 can access the thread context 202, and code executing at the asynchronous thread 207 can access the thread context 208).

[0024] As a non-limiting illustration, the.NET framework includes a ‘CancellationTokenSource’ type that has two uses. First, it returns a ‘CancellationToken’ object that can be passed as a parameter to an asynchronous method call. Second, it provides a Cancel method for signaling that the associated operation should be canceled. Thus, an application can hand a CancellationToken to any entity that wants to listen for a cancellation signal, and any listening entity is notified when the Cancel method is called on the associated CancellationTokenSource object. Example 1 shows an example signature of a ReadAsync asynchronous method that takes a CancellationToken.

[0025] public Task <int>ReadAsync(byte[]buffer,int length,int offset,

[0026] CancellationToken cancellationToken);

[0027] Example 1

[0028] It is worth noting that, as shown in Example 2, in the .NET Framework, synchronous methods lack awareness of CancellationToken.

[0029] public int Read(byte[]buffer,int length,int offset);

[0030] Example 2

[0031] If the Cancel method on a CancellationToken is called while a ReadAsync instance that is passed a CancellationToken is running, the ReadAsync instance will wake up from its I / O operation and complete with an OperationCanceledException, which in turn is propagated to any entity awaiting the returned Task.

[0032] exist Figure 1 , the language runtime 110 is illustrated as including a green thread manager 114, indicating that in the embodiments described herein, the language runtime 110 supports implicitly specified asynchronous operations (e.g., a green thread model) in addition to explicitly specified asynchronous operations (e.g., a callback model). This means that the language runtime 110 also enables the application 111 to queue work at the thread pool 112 via a green thread that calls a synchronization method 117. In some embodiments, the synchronization method 117 is part of the language runtime 110 and utilizes system calls 113 to perform synchronization work (e.g., by calling a synchronous version of a system call, such as the Read method). In other embodiments, the synchronization method 117 itself is one of the system calls 113.

[0033] In the embodiments described herein, the language runtime 110 enables the combination of these two models, meaning that an application (e.g., application 111) can use both explicit asynchrony (callback model) and implicit asynchrony (green thread model). Because synchronous methods lack awareness of cancellation tokens, one challenge in combining these models is that if an application uses synchronous methods with green threads, there is nowhere to pass a cancellation token (e.g., a CancellationToken object in the .NET Framework).

[0034] To address these challenges, the embodiments described herein extend the language runtime 110 API for starting or queuing green threads so that the API supports the concept of cancellation tokens. This includes extending the API to insert cancellation tokens into the environment context associated with a green thread. Figure 1 , the green thread creation component 115 is illustrated as including an environment context component 116 that identifies a cancellation token and inserts the cancellation token into the environment context of the green thread when the green thread is created or queued.

[0035] In some embodiments, the green thread creation component 115 receives a cancellation token from the calling context. As a non-limiting illustration, Example 3 shows that the signature of the RunOnGreenThread method of the .NET framework can be extended to accept a CancellationToken object.

[0036]

[0037] Example 3

[0038] In other embodiments, the green thread creation component 115 generates a cancellation token itself and returns the cancellation token to the calling context.

[0039] In either case, the environment context component 116 stores the cancellation token in a manner that is accessible to any code running on the newly created / enqueued green thread. In one embodiment, the environment context component 116 stores the cancellation token in the thread's global context. In some embodiments, the environment context component 116 also stores an indication that the thread has a green thread type.

[0040] As a non-limiting illustration, Example 4 shows the creation of an ambient context, including storing a cancellation token and an indication of a green thread type.

[0041]

[0042] Example 4

[0043] The embodiments described herein also provide a mechanism to replace a synchronous method implementation with an asynchronous equivalent method when the asynchronous method implementation is executed on a green thread, utilizing the ambient context. One embodiment implants detection logic into a synchronous method (e.g., within system call 113) that utilizes the ambient context of the thread being executed to determine whether it is executing on a green thread. If it is not executing on a green thread, the detection logic continues with the synchronous implementation of the method. If it is executing on a green thread, the detection logic uses a cancellation token obtained from the ambient context of the thread to invoke the asynchronous equivalent method of the synchronous method. For example, when invoked, a synchronous method (e.g., 'Read') utilizes the ambient context to determine whether it is executing on a green thread. If it is not executing on a green thread, the method continues with its synchronous implementation. If it is executing on a green thread, the method invokes the synchronous implementation (e.g., 'ReadAsync') and passes the cancellation token obtained from the ambient context to the synchronous implementation. In Figure 1 In the example 300, the detection logic is illustrated as green thread logic 118 of the synchronous method 117.

[0044] By way of non-limiting illustration, Example 5 illustrates how a synchronous Read method of the.NET framework can be instrumented with detection according to the embodiments described herein to take the ambient thread context (including the ambient CancellationToken) as part of its internal delegate to the corresponding asynchronous operation.

[0045]

[0046] Example 5

[0047] Figure 3 An example 300 of a synchronous method call is illustrated, where the synchronous method continues synchronously based on the ambient context. In the example 300, an application thread 301 (e.g., application 111) makes a synchronous method call 304 to a synchronous method 308. This results in the creation of a synchronous thread 305 (e.g., by the language runtime 110) for execution at a thread pool (e.g., thread pool 112). Notably, in the example 300, the application thread 301 has a thread context 302 (ambient context) that indicates the thread type 303 of the application thread 301, and the synchronous thread 305 has a thread context 306 (ambient context) that indicates the thread type 307 of the synchronous thread 305. Here, the thread type 307 indicates that the synchronous thread 305 is not a green thread. Thus, when the synchronous method 308 utilizes the ambient context (e.g., thread context 306) to determine (e.g., green thread logic 118) whether it is executing on a green thread (check thread type 309), it determines that it is not executing on a green thread and continues with the synchronous implementation 310. Figure 3

[0048] ​ Figure 4 An example 400 of a synchronous method call is shown, where the synchronous method calls an asynchronous implementation based on the environment context. In example 400, an application thread 401 (e.g., application 111) queues a green thread (queued green thread 405) for execution of a synchronous method 410. This results in the creation of a green thread 407 (e.g., by language runtime 110) for execution at a thread pool (e.g., thread pool 112). As with examples 200 and 300, each of application thread 401 and green thread 407 has a thread context 402, 408 (environment context) that indicates, for example, the thread type 403, 409 of the thread. However, unlike examples 200 and 300, in example 400, thread context 408 also includes a cancellation token 406. In some embodiments, cancellation token 406 is generated by green thread creation component 115 as part of the creation / queuing process of green thread 407. In other embodiments, as shown in example 400, application thread 401 creates a cancellation token (create cancellation token 404) and passes that token when it queues green thread 407. Here, thread type 409 indicates that green thread 407 is a green thread. Thus, when synchronous method 410 uses the environment context (e.g., thread context 408) to determine (e.g., green thread logic 118) whether it is executing on a green thread (check thread type 411), it determines that it is executing on a green thread. Thus, synchronous method 410 calls an asynchronous method 413 (asynchronous method call 412) and passes to it cancellation token 406 (as obtained from thread context 408). Figure 4

[0049] In this way, developers are able to write synchronous code using synchronous methods that have existed for many years without having to worry about the impact of cancellation on the programming model. However, language runtime 110 ensures that this synchronous code is implemented asynchronously in a cancellation-compatible manner when possible. By way of non-limiting illustration, a developer can use synchronous Read and Write methods as shown in example 6:

[0050]

[0051] Example 6

[0052] This synchronous code can then be used with a cancellation token that is able to cancel all involved synchronous operations as shown in example 7.

[0053]

[0054] Example 7

[0055] ​As an alternative to implanting detection logic into synchronous methods to determine whether they are executing on a green thread, another embodiment (e.g., performed by the language runtime 110) detects calls to synchronous methods. Then, before executing the call, the language runtime 110 uses the environment context of the thread making the call to determine whether the thread making the call is a green thread. If the thread is not a green thread, the language runtime 110 continues the call to the synchronous method in the normal way. However, if the thread is a green thread, the language runtime 110 uses the cancellation token obtained from the thread's environment context to continue the call to the asynchronous equivalent method.

[0056] In some embodiments, the environment context is stored as part of the thread itself (e.g., thread contexts 202, 208, 302, 306, 402, 408). In other embodiments, the environment context is stored outside of the thread. These embodiments enable cancellation to flow in with the asynchronous operation used. For example, the.NET framework has the concept of 'AsyncLocal', which is a state associated with a thread. In embodiments, constructs such as 'AsyncLocal' are extended to flow with the asynchronous operation in an environmental manner, so that any thread that runs the code associated with the operation also sees the state associated with that thread. Thus, as an alternative to storing the cancellation token on the green thread, it can be stored in AsyncLocal <cancellationtoken>In particular, the configuration is such that it is accessible to a synchronization operation running on a green thread and is visible to any other thread running the executed asynchronous operation.

[0057] In embodiments, when an asynchronous task initiated as part of a green thread based on an environmental context is cancelled, its cancellation is propagated via an exception, such as an 'OperationCanceledException' in the.NET framework, to any entity listening for the exception.

[0058] Embodiments will now be described with reference to the following drawings: Figure 5 Figure 5 A flowchart illustrating an example method 500 for converting a synchronization operation to an asynchronous operation using an environmental context when the synchronization operation is executed on a green thread is shown. In embodiments, instructions for implementing method 500 are encoded as computer-executable instructions stored on a computer storage medium (e.g., storage medium 104) that are executable by a processor (e.g., processor system 102) to cause a computer system (e.g., computer system 101) to perform method 500.

[0059] The following discussion discusses methods and method actions. Although method actions are discussed in a particular order or shown in a particular order in a flowchart, a particular order is not required unless explicitly stated or because one action depends on another action being completed before the action is performed.

[0060] Reference is made to Figure 5 In embodiments, method 500 includes an action 501 of queuing a thread for execution by a thread pool. For example, language runtime 110 creates / queues a thread for execution on thread pool 112. This can be a thread that executes a synchronization method (e.g., synchronization thread 305). Alternatively, green thread creation component 115 can create / queue a green thread that executes a synchronization method (green thread 407). In embodiments, the thread pool is managed by OS 109 or language runtime 110.

[0061] In some embodiments, action 501 includes an action 502 of configuring an environmental context with a cancellation token. For example, when green thread creation component 115 creates green thread 407, environmental context component 116 configures the environmental context with a cancellation token. For example, thread context 408 of green thread 407 includes cancellation token 406.

[0062] ​In some embodiments, the cancellation token is generated by the entity that queues / creates the thread. For example, the green thread creation component 115 creates the cancellation token and passes the token back to the caller. In other embodiments, the cancellation token is passed to the method that queues / creates the thread by the caller. For example, the application thread 401 creates the cancellation token 406 (create cancellation token 404) and passes the cancellation token 406 to the green thread creation component 115. In embodiments, configuring the environment context includes configuring the environment context with an indication that the thread uses the green thread model. For example, the thread context 408 of the green thread 407 includes a thread type 409 (e.g., configured by the environment context component 116).

[0063] As shown in act 503, the thread calls the synchronization method without using the cancellation token. For example, the synchronization thread 305 calls the synchronization method 308, or the green thread 407 calls the synchronization method 410. Accordingly, the method 500 further includes an act 504 of determining whether the thread uses the green thread model. In some embodiments, act 504 includes determining whether the thread uses the green thread model based on the thread's call to the synchronization method. In one example, based on the call to the synchronization method 308, the thread context 306 is used to determine that the synchronization thread 305 is not a green thread (e.g., based on the thread type 307). In another example, based on the call to the synchronization method 410, the thread context 408 is used to determine that the green thread 407 is a green thread (e.g., based on the thread type 409 or based on the presence of the cancellation token 406).

[0064] In some embodiments, act 504 is performed by the language runtime 110 based on the language runtime 110 identifying the call to the synchronization method. Accordingly, in embodiments, the language runtime identifies the cancellation token from the environment context and calls the asynchronous method. In other embodiments, act 504 is performed by the green thread logic 118 that is implanted in the synchronization method. Accordingly, in embodiments, the synchronization method identifies the cancellation token from the environment context and calls the asynchronous method.

[0065] In some embodiments, the result of act 504 is a determination that the thread does not use the green thread model. In some embodiments, the determination that the thread does not use the green thread model is based on an indication identified from the environment context. For example, the green thread logic 118 identifies the thread type 307 in the thread context 306. In some embodiments, the determination that the thread does not use the green thread model is based on a lack of a cancellation token in the environment context. For example, the green thread logic 118 determines that the thread context 408 lacks any cancellation token and infers that the green thread 407 is not a green thread by the lack of a token.

[0066] In some embodiments, the result of action 504 is a determination that the thread uses a green thread model. In some embodiments, the determination that the thread uses a green thread model is based on an identification of an indication from the environmental context. For example, the green thread logic 118 identifies the thread type 409 in the thread context 408. In some embodiments, the determination that the thread uses a green thread model is based on an identification of a cancellation token from the environmental context. For example, the green thread logic 118 identifies the cancellation token 406 in the thread context 408, and infers that the green thread 407 is a green thread by the presence of the token.

[0067] When the thread is determined not to use a green thread model in action 504 (e.g., the "No" branch of action 504), the method 500 further includes an action 505 to continue synchronously. In some embodiments, action 505 includes performing a task of the synchronous method based on the thread not using a green thread model. For example, based on the green thread logic 118 determining that the synchronous thread 305 is not a green thread, the synchronous method 308 continues using the synchronous implementation 310.

[0068] When the thread is determined to use a green thread model in action 504 (e.g., the "Yes" branch of action 504), the method 500 further includes an action 506 to invoke an asynchronous method using a cancellation token. In some embodiments, action 506 includes invoking an asynchronous method that uses an asynchronous operation to perform a task of the synchronous method based on the thread using a green thread model, including passing the cancellation token to the asynchronous method, based on the thread using a green thread model.

[0069] In one example, based on the language runtime 110 determining that the green thread 407 is a green thread, the language runtime 110 replaces the call to the synchronous method 410 with a call to the asynchronous method 413, and passes the cancellation token 406 from the thread context 408 to it. In another example, based on the green thread logic 118 determining that the green thread 407 is a green thread, the synchronous method 410 invokes the asynchronous method 413, and passes the cancellation token 406 from the thread context 408 to it. In either example, action 506 includes identifying the cancellation token from the environmental context.

[0070] After action 506, the method 500 can further include an action 507 to terminate the asynchronous operation based on the cancellation token. In some embodiments, action 507 includes terminating the asynchronous operation based on an identification of a state change of the cancellation token. For example, based on the application thread 401 invoking the Cancel method of the cancellation token 406, the asynchronous method 413 identifies the signal from the cancellation token 406 and terminates its asynchronous operation. In some embodiments, the identification of the state change of the cancellation token is based on a polling of the cancellation token.

[0071] In embodiments, cancellation of the asynchronous operation signals the parent context(s) via an exception after action 507. Thus, in some embodiments, the method 500 includes propagating an exception to a context waiting for the thread based on terminating the asynchronous operation.

[0072] Embodiments of the disclosure can include or utilize a special-purpose or general-purpose computer system (e.g., computer system 101) that includes computer hardware, such as a processor system (e.g., processor system 102) and system memory (e.g., memory 103), as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 104). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Thus, embodiments of the present disclosure can include at least two distinct computer-readable media: computer storage media and transmission media.

[0073] Computer storage media is physical storage media that stores computer-executable instructions and / or data structures. Physical storage media includes computer hardware, such as random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage devices (one or more) that can be used to store program code in the form of computer-executable instructions or data structures and that can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[0074] Transmission media can include a network and / or data links that can carry program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer system. A "network" is defined as one or more data links that enable the transport of electronic data between computer systems and / or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the computer system can view the connection as transmission media. Combinations of the above are included within the scope of computer-readable media.

[0075] Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received by way of network or data link can be buffered in RAM within a network interface module (e.g., network interface 105), and then eventually transferred to computer system RAM and / or to less volatile computer storage media at a computer system. Thus, computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0076] Computer-executable instructions comprise, for example, instructions and data which, when executed at one or more processors, cause a general-purpose computer system, special-purpose computer system, or special-purpose processing devices to perform a certain function or group of functions. Note that computer-executable instructions can be software codes, which are executable by one or more processors implemented as general-purpose computers, special-purpose computers, or special-purpose processing devices. Computer-executable instructions can be stored as computer-executable codes or machine-readable instructions on one or more computer-readable media (e.g., computer-readable storage media such as magnetic disks, optical disks, read-only memory (ROM), random-access memory (RAM), and the like).

[0077] It is understood that the disclosed systems and methods can be practiced within a network computing environment, comprising a personal computer, a desktop computer, a notebook computer, a message processor, a handheld device, a multi-processor system, a microprocessor-based or programmable consumer electronics, a network PC, a minicomputer, a mainframe computer, a mobile telephone, a PDA, a tablet computer, a pager, a router, a switch, and the like. Embodiments of the present disclosure can also be practiced in a distributed system environment, in which local and remote computer systems both perform tasks. In a distributed system environment, computer systems can include multiple constituent computer systems. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0078] It should also be understood that embodiments of the present disclosure can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When the cloud computing environment is distributed, cloud computing environment can be distributed internationally within an organization and / or have components possessed by multiple organizations. In this description and the following claims, "cloud computing" is used to describe a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). Cloud computing can be composed of various characteristics such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and the like. Cloud computing can also employ various deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and the like. Cloud computing can also be deployed using various service models such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

[0079] Some embodiments, such as cloud computing environments, can include a system that includes one or more hosts capable of running one or more virtual machines. During operation, a virtual machine emulates a running computing system that supports an OS and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources of a virtual machine using physical resources that are abstracted from the view of the virtual machine. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine is only interfacing with an appearance of the physical resource (e.g., a virtual resource). Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, and the like.

[0080] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, nor to the described order of acts. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0081] The present disclosure can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. All changes coming within the meaning and equivalency range of the claims are intended to be embraced therein.

[0082] In the elements introduced in the appended claims, the articles "a," "an," "the," and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there can be additional elements other than the listed elements. The terms "set," "superset," and "subset" are intended to exclude the empty set, unless otherwise specified, so "set" is defined as a non-empty set, "superset" is defined as a non-empty superset, and "subset" is defined as a non-empty subset. Unless otherwise specified, the term "subset" does not include the entirety of its superset (i.e., the superset contains at least one item not included in the subset). Unless otherwise specified, "superset" can include at least one additional element, and "subset" can exclude at least one element.< / cancellationtoken> < / int>

Claims

1. A method (500) implemented in a computer system (100), the computer system including a processor system (102), the method comprising: enqueueing (115) a thread (407) for execution by a thread pool (112), including configuring (116) an environment context (408) with a cancellation token (406); Based on a call to a synchronization method (117) by said thread, Determining (118) that the thread uses a green thread model; as well as identifying (118) the cancellation token from the environmental context; Based on the thread using the green thread model, calling (118) an asynchronous method (119), the asynchronous method using asynchronous operations to perform the task of the synchronous method, including passing the cancellation token to the asynchronous method; as well as The asynchronous operation is terminated (110) based on identifying a change in state of the cancellation token. The method according to claim 1 , wherein the thread pool is an input / output thread pool.

3. A method according to claim 1 or claim 2, wherein the cancellation token is passed to a method that queues the thread.

4. The method of claim 1 or claim 2, wherein the cancellation token is generated by a method that queues the thread.

5. The method according to any one of claims 1 to 4, wherein The method further includes configuring the environment context with an indication that the thread uses the green thread model, and Determining that the thread uses the green thread model is based on identifying the indication from the environmental context. 6 . The method according to claim 1 , wherein determining that the thread uses the green thread model is based on identifying the cancellation token from the environment context.

7. The method according to any one of claims 1 to 6, wherein the method further comprises: Upon terminating the asynchronous operation, an exception is propagated to a context awaiting the thread.

8. The method according to any one of claims 1 to 7, wherein the method further comprises identifying the change in state of the cancellation token based on polling the cancellation token.

9. The method of any one of claims 1 to 8, wherein the synchronous method identifies the cancellation token from the ambient context and calls the asynchronous method.

10. The method of any one of claims 1 to 9, wherein a language runtime identifies the cancellation token from the ambient context and calls the asynchronous method.

11. A computer system (100), comprising: Processor system (102); as well as A computer storage medium (104) storing computer-executable instructions (110) executable by the processor system to at least: creating (115) a thread (407) for execution by the thread pool (112), including configuring (116) an environment context (408) using a cancellation token (406); Based on the call to the synchronization method (117) by the thread: determining (118) that the thread uses a green thread model; and identifying (118) the cancellation token from the environmental context; Based on the thread using the green thread model, calling (118) an asynchronous method (119), the asynchronous method using asynchronous operations to perform the task of the synchronous method, including passing the cancellation token to the asynchronous method; as well as The asynchronous operation is terminated (110) based on identifying a change in state of the cancellation token.

12. The computer system of claim 11, wherein the cancellation token is passed to a method that creates the thread.

13. The computer system of claim 11, wherein the cancellation token is generated by a method that creates the thread.

14. The computer system according to any one of claims 11 to 13, wherein: The computer-executable instructions are further executable by the processor system to configure the environmental context with an indication that the thread utilizes the green thread model, and Determining that the thread uses the green thread model is based on identifying the indication from the environmental context. 15 . The computer system of claim 11 , wherein determining that the thread uses the green thread model is based on identifying the cancellation token from the environment context.

16. The computer system of any one of claims 11 to 15, wherein the computer executable instructions are further executable by the processor system to propagate an exception to a context waiting on the thread upon terminating the asynchronous operation.

17. The computer system of any one of claims 11 to 16, wherein the computer-executable instructions are further executable by the processor system to identify the change in state of the revocation token based on polling the revocation token.

18. The computer system of any one of claims 11 to 17, wherein the synchronous method identifies the cancellation token from the ambient context and calls the asynchronous method.

19. The computer system of any one of claims 11 to 18, wherein the language runtime identifies the cancellation token from the ambient context and calls the asynchronous method.

20. A method (500) implemented in a computer system (100), the computer system comprising a processor system (102), the method comprising: Queuing (115) the thread (305) for execution by the thread pool (112); Based on a call to a synchronization method (117) by the thread, determining (118) that the thread is not using a green thread model; and Based on the thread not using the green thread model, performing (118) the task of the synchronization method.

Images