What is the difference between asymmetric and symmetric coroutines? - coroutine

I noticed that support for symmetric coroutines was removed in Boost.Coroutine2 for C++, so I wanted to understand -- what is the difference between the two?

The difference between symmetric and asymmetric coroutines is described particularly well by Ana Lúcia de Moura and Roberto Ierusalimschy in their paper "Revisiting Coroutines":
A well-known classification of coroutines concerns the control-transfer operations that are provided and distinguishes the concepts of symmetric and asymmetric coroutines. Symmetric coroutine facilities provide a single control-transfer operation that allows coroutines to explicitly pass control between themselves. Asymmetric coroutine mechanisms (more commonly denoted as semi-symmetric or semi coroutines) provide two control-transfer operations: one for invoking a coroutine and one for suspending it, the latter returning control to the coroutine invoker. While symmetric coroutines operate at the same hierarchical level, an asymmetric coroutine can be regarded as subordinate to its caller, the relationship between them being somewhat similar to that between a called and a calling routine.
Coroutine mechanisms to support concurrent programming usually provide symmetric coroutines to represent independent units of execution, like in Modula-2. On the other hand, coroutine mechanisms intended for implementing constructs that produce sequences of values typically provide asymmetric coroutines. Examples of this type of construct are iterators and generators.
(Citations omitted)
In the asymmetric coroutine model, "asymmetry" refers to the fact that there is a stack-like caller–callee relationship between coroutines. A coroutine can either call another coroutine or suspend itself by yielding control to its caller, typically also yielding a value to the caller at the same time.
In the symmetric coroutine model, a coroutine may yield control to any other coroutine without restriction.
The two models actually have the same expressive power; i.e. asymmetric coroutines can be implemented using symmetric coroutines and vice versa. (See Symmetric coroutines, written by Giovanni P. Deretta, for a transformation between the two types of coroutines.) Consequently, Moura and Ierusalimschy write: "Providing both constructs only complicates the semantics of the [coroutine] mechanism, with no increase in its expressive power."
The developers of Coroutine2 decided not to provide symmetric coroutines in the library because they believe that symmetric coroutine functionality is better implemented by boost::context::execution_context (part of Boost.Context): http://lists.boost.org/Archives/boost/2015/06/223701.php

Coroutines switch between caller and callee, e.g. you enter the coroutine-function and you switch back to the calling code. Usually (asymmetric) coroutines have two functions for this purpose:
a resume-function that is called by the caller
a suspend-function that is called from within the coroutine
Because you have two functions to switch the context, it is called asymmetric.
Symmetric coroutines have only one function that suspends the current context and resumes another one. Note that you have to specify which symmetric coroutine has to be resumed next.
Symmetric coroutines can be used to implement user-land threads (a symmetric coroutine represents a userland thread; the scheduler jumps from one coroutine to the next symmetric coroutine, e.g. the next user-land thread is scheduled) more efficiently than asymmetric coroutines.
This is obvious because symmetric coroutines do not need to jump back to the caller in order to resume the next user-land thread. Asymmetric coroutines need more context switches than symmetric coroutines in order to achive the same functionality.
Symmetric coroutines - symmetric context switching - is better represented by concepts like 'call with current continuation' (Scheme, Ruby ...).
boost.context supports this concept with its implementation of callcc()/continuation.
Therefore boost.coroutine2 does not provide a symmetric coroutine API - but the asymmetric coroutine of boost.coroutine2 is implemented with boost.context's callcc()/continuation.

Related

Kotlin coroutines. Unconfined dispatcher - concrete use cases?

Kotlin docs mention unconfined dispatcher.
Well, it is quite clear - an execution is not confined to a particular thread.
We see 2 passages
The unconfined dispatcher is an advanced mechanism that can be helpful in certain corner cases where dispatching of a coroutine for its execution later is not needed or produces undesirable side-effects, because some operation in a coroutine must be performed right away. The unconfined dispatcher should not be used in general code.
Unconfined dispatcher is appropriate when coroutine does not consume CPU time nor updates any shared data (like UI) that is confined to a specific thread.
those sound very abstract.
Question: Could anyone give 1-2-3 concrete use cases when you used this type of dispatcher? What are those "corner cases"? Even quite a good book "Kotlin Coroutines by Tutorials" skips details on this topic.
Thanks

Unnecessarily mark functions as suspending in favor of common abstraction

I'm working on a project with an API running in the JVM and a JS client to access this API from the browser. The data classes of those objects which are converted to/from JSON are in a multiplatform module so that I can reuse the code on both platforms and don't accidentally end up with mismatched attributes. At this point it would be nice to also have the APIs interface in this mutliplatform module which then would be implemented and hosted in the JVM and implemented and presented in the browser. However, all methods of this interface need to be suspending in the browser since requests are (at least with Ktor's client, which I'm using) while they do not need to be suspending in the JVM.
Is there a good reason against having all those methods suspending even though I don't make use of it in the JVM? I know that methods usually should be suspending only if it's actually needed, but then I would be writing all the same interfaces (besides the suspend keyword) twice which seems like a lot of unnecessary boilerplate code to me. The methods which would unnecessarily be marked as suspending are called from suspending contexts (I'm using Ktor in the JVM too) so restricted usage wouldn't be a problem.
This seems like a matter of preference, really. Both using suspend and not using it have disadvantges, so you have to choose which weigh less.
From what you write, it seems that the advantages of using suspend (write code only once) outweigh the disavantage of polluting the interface with an unnecessary modifier. I am not aware of the possible runtime overheads here. Personally, I would opt to go with suspend.
The methods which would unnecessarily be marked as suspending are called from suspending contexts (I'm using Ktor in the JVM too) so restricted usage wouldn't be a problem.
This is the key point: the biggest hassle of the unnecessary suspend is having to launch a coroutine. If you're already inside a coroutine, the overhead of just one function along the call path being unnecessarily suspend is very low: a single extra object allocated per call.
While it's true that with having one interface you avoid boilerplate and you get the hassle of having to launch a coroutine on JVM, I'd consider another perspective:
When designing your abstraction IMO you shouldn't get much into implementation details, instead of thinking how jvm and/or js handles communication with the api I'd go with the question "Do I want to leave room for the platforms to handle this communication in an async/suspend way?". I believe this way you'll arrive to a more scalable solution, but true you'll lose out on some of the micro-optimizations

How to understand coroutine cancellation is cooperative

In Kotlin, coroutine cancellation is cooperative. How should I understand it?
Link to Kotlin documentation.
If you have a Java background, you may be familiar with the thread interruption mechanism. Any thread can call thread.interrupt() and the receiving thread will get a signal in the form of a Boolean isInterrupted flag becoming true. The receiving thread may check the flag at any time with currentThread.isInterrupted() — or it may ignore it completely. That's why this mechanism is said to be cooperative.
Kotlin's coroutine cancellation mechanism is an exact replica of this: you have a coroutineContext.isActive flag that you (or a function you call) may check.
In both cases some well-known functions, for example Thread.sleep() in Java and delay() in Kotlin, check this flag and throw an InterruptedException and CancellationException, respectively. These methods/functions are said to be "interruptible" / "cancellable".
I'm not 100% sure whether I understand your question, but maybe this helps:
Coroutines are usually executed within the same thread you start them with. You can use different dispatchers, but they are designed to work when being started from the same thread. There's no extra scheduling happening.
You can compare this with scheduling mechanisms in an OS. Coroutines behave similar like to cooperative scheduling. You find similar concepts in many frameworks and languages to deal with async operations. Ruby for example has fibers which behave similar.
Basically this means that if a coroutine is hogging on your CPU in a busy loop, you cannot cancel it (unless you kill the whole process). Instead, your coroutines has to regularly check for cancellation and also add waits/delays/yields so that other coroutines can work.
This also defines on when coroutines are helpful the most: when running in a single-threaded-context, it doesn't help to use co-routines for local-only calculations. I used them mostly for processing async calls like interactions with databases or web servers.
This article also has some explanations on how coroutines work - maybe it helps you with any additional questions: https://antonioleiva.com/coroutines/

Can `SendChannel.offer`, `CompletableDeferred.complete`, and similar be called outside coroutines?

CompletableDeferred documentation says
All functions on this interface and on all interfaces derived from it are thread-safe and can be safely invoked from concurrent coroutines without external synchronization.
Is it safe to call these functions outside any coroutine?
For SendChannel<E>, offer and close are not suspend and so they can be called outside coroutines syntactically, but is it actually safe to do so?
If a coroutine is needed, what is the cheapest way to start one: launch(Unconfined)?
It is safe to call offer and close from anywhere. That is what documentation means to say with "are thread-safe" phrase.
One of the reasons these methods are included into channel APIs is to enable integration of coroutines with the regular non-coroutine world that is based on various callbacks and event handlers. You can see the actual example of such integration in this guide on UI programming with coroutines.

Kotlin Coroutines: Do we need to synchronize shared state?

From the official guide and samples from web, I didn't see any mentions of locking or synchronization, or how safe is modifying a shared variable in multiple launch or async calls.
Coroutines bring a concurrent programming model that may result in simultaneously executed code. Just as you know it from thread-based libraries, you have to care about synchronization as noted in the docs:
Coroutines can be executed concurrently using a multi-threaded dispatcher like the Dispatchers.Default. It presents all the usual concurrency problems. The main problem being synchronization of access to shared mutable state. Some solutions to this problem in the land of coroutines are similar to the solutions in the multi-threaded world, but others are unique.
With Kotlin Coroutines you can make use of acquainted strategies like using thread-safe data structures, confining execution to a single thread or using locks (e.g. Mutex).
Besides the common patterns, Kotlin coroutines encourage us to use a "share by communication" style. Concretely, an "actor" can be shared between coroutines. They can be used by coroutines, which may send/take messages to/from it. Also have a look at Channels.