This is the twelfth part of the Async Wandering series. For your convenience you can find other parts in the table of contents in Part 1 – Why creating Form from WinForms in unit tests breaks async?

Today we are going to color our functions in different way.

Last time we saw how to return values from each function using monads. However, all we need is just an ability to run the code in some context if we expect that code may be asynchronous. If we know it’s going to be synchronous then there is no reason to go through any monads. Instead of reverse-colouring functions, we may use generics to propagate the context and call it as needed.

public abstract class Builder
{
	public abstract Monad Build();
}

public class IdBuilder : Builder
{
	public override Monad Build()
	{
		return new Id();
	}
}

public class AsyncBuilder : Builder
{
	public override Monad Build()
	{
		return new Async();
	}
}

public interface Monad
{
	U Map(T value, Func lambda);
	void Complete(object t);
}

public class Id : Monad
{
	private object t;

	public U Map(T value, Func lambda)
	{
		this.t = value;
		lock (this)
		{
			while (t == null)
			{
				Monitor.Wait(this);
			}
		}

		return lambda((T)this.t);
	}

	public void Complete(object t)
	{
		lock (this)
		{
			this.t = t;
			Monitor.PulseAll(this);
		}
	}
}

public class Async : Monad
{
	private object t;
	private int current;

	public U Map(T value, Func lambda)
	{
		this.t = value;
		if (t == null)
		{
			this.current = HKTMonadFiberAsync.current;
			byte b;
			HKTMonadFiberAsync.readyToGo.TryRemove(this.current, out b);
			HKTMonadFiberAsync.helper.Switch(0);
		}

		return lambda((T)this.t);
	}

	public void Complete(object t)
	{
		this.t = t;
		HKTMonadFiberAsync.readyToGo.TryAdd(this.current, 0);
	}
}

Super similar to the code from the last part. However, this time we don’t hold the value in the monad, we pass it as a parameter and run it through the context.

How do we use it? This way:

private static void RunInternal()
{
	WhereAmI("Before nesting");

	RunInternalNested<AsyncBuilder>();

	WhereAmI("After nesting");
}

private static void RunInternalNested() where T: Builder, new()
{
	WhereAmI("Before creating delay");

	Delay<T>(2000);

	WhereAmI("After sleeping");

	var data = Data<T>("Some string");
	
	WhereAmI($"After creating data {data}");
}

private static void Delay(int timeout) where T : Builder, new()
{
	var context = new T().Build();
	var timer = new Timer(_ => context.Complete(new object()), null, timeout, Timeout.Infinite);
	GC.KeepAlive(timer);
	context.Map((object)null, _ => timeout);
}

private static U Data(U d) where T: Builder, new()
{
	var context = new T().Build();
	return context.Map(d, _ => d);
}

notice that call to Delay passes the generic parameter indicating the context. We can also wrap any value through the context, just like Task.FromResult if needed. And the output is as expected:

Thread 1 Time 8/12/2020 5:16:21 PM: Start - HKTMonadFiberAsync
Thread 1 Time 8/12/2020 5:16:21 PM: Before nesting
Thread 1 Time 8/12/2020 5:16:21 PM: Before creating delay
Thread 1 Time 8/12/2020 5:16:21 PM: Side job
Thread 1 Time 8/12/2020 5:16:23 PM: After sleeping
Thread 1 Time 8/12/2020 5:16:23 PM: After creating data Some string
Thread 1 Time 8/12/2020 5:16:23 PM: After nesting
Thread 1 Time 8/12/2020 5:16:23 PM: End - HKTMonadFiberAsync

See that the side job was executed when we were sleeping. But if we change line 5 to RunInternalNested< IdBuilder>();, we get this:

Thread 1 Time 8/12/2020 5:17:10 PM: Start - HKTMonadFiberAsync
Thread 1 Time 8/12/2020 5:17:10 PM: Before nesting
Thread 1 Time 8/12/2020 5:17:10 PM: Before creating delay
Thread 1 Time 8/12/2020 5:17:12 PM: After sleeping
Thread 1 Time 8/12/2020 5:17:12 PM: After creating data Some string
Thread 1 Time 8/12/2020 5:17:12 PM: After nesting
Thread 1 Time 8/12/2020 5:17:12 PM: Side job
Thread 1 Time 8/12/2020 5:17:12 PM: End - HKTMonadFiberAsync

So the side job is executed after the main one finishes which is a synchronous execution.

This way we have no colors, no static state, just a generic parameter which could be optimized by the compiler. We can go even further and get rid of boxing:

public abstract class Builder
{
	public abstract Monad Build();
}

public class IdBuilder : Builder
{
	public override Monad Build()
	{
		return new Id();
	}
}

public class AsyncBuilder : Builder
{
	public override Monad Build()
	{
		return new Async();
	}
}

public interface Monad
{
	U Map<U>(T value, Func lambda);
	void Complete(T t);
}

public class Id : Monad
{
	private T t;

	public U Map<U>(T value, Func lambda)
	{
		this.t = value;
		lock (this)
		{
			while (t == null)
			{
				Monitor.Wait(this);
			}
		}

		return lambda(this.t);
	}

	public void Complete(T t)
	{
		lock (this)
		{
			this.t = t;
			Monitor.PulseAll(this);
		}
	}
}

public class Async : Monad
{
	private T t;
	private int current;

	public U Map<U>(T value, Func lambda)
	{
		this.t = value;
		if (t == null)
		{
			this.current = HKTMonadFiberAsync.current;
			byte b;
			HKTMonadFiberAsync.readyToGo.TryRemove(this.current, out b);
			HKTMonadFiberAsync.helper.Switch(0);
		}

		return lambda(this.t);
	}

	public void Complete(T t)
	{
		this.t = t;
		HKTMonadFiberAsync.readyToGo.TryAdd(this.current, 0);
	}
}

Bonus points for getting sort of Higher Kinded Type in C# without doing the Brand transformation.

This is the eleventh part of the Async Wandering series. For your convenience you can find other parts in the table of contents in Part 1 – Why creating Form from WinForms in unit tests breaks async?

We continue exploring async code.

Last time we saw how to use fibers to wait tasks. This effectively allows us to have async code without any function coloring.

We already know function coloring has big drawbacks and I also provided an example how to use monads to address that. However, monads were actually reverse-coloring everything, instead of having functions of two colors (one for sync and one for async) we had all functions of the same color with some monad type returned.

Today we are going to merge that approach. We’ll have reverse-colored functions with fibers. Let’s begin.

I start with the same glue code as the last time:

public static ConcurrentDictionary readyToGo = new ConcurrentDictionary();
public static ConcurrentDictionary allJobs = new ConcurrentDictionary();
public static AsyncLoomCli.FiberHelper helper = new AsyncLoomCli.FiberHelper();
public static int current;
public static bool done;

public static int StartFiber(string arg)
{
	int actionId = (int)arg[0];
	allJobs[actionId]();
	if (actionId != 0)
	{
		MonadFiberAsync.done = true;
		MonadFiberAsync.helper.Switch(0);
	}

	return 0;
}

public static void Run()
{
	helper.Convert();

	allJobs.TryAdd(1, RunInternal);
	readyToGo.TryAdd(1, 0);
	helper.Create(1);

	allJobs.TryAdd(2, SideJob);
	readyToGo.TryAdd(2, 0);
	helper.Create(2);


	while (true)
	{
		done = false;
		var keys = readyToGo.Keys.GetEnumerator();
		while (keys.MoveNext())
		{
			current = keys.Current;
			helper.Switch(current);
			if (done)
			{
				helper.Delete(current);
				Action action;
				allJobs.TryRemove(current, out action);
				byte b;
				readyToGo.TryRemove(current, out b);
			}
		}

		if (allJobs.IsEmpty)
		{
			break;
		}

		Thread.Sleep(1);
	}
}

Next, I introduce monads:

public interface Monad
{
	Monad<U> Map<U>(Func<T, Monad<U>> lambda);
	void Complete(T t);
	T Value();
}

Super simple interface, not adhering to all monad laws. This is just for showing the idea, not a bullet proof implementation.

We go with this base class:

public abstract class BaseMonad : Monad
{
	public T Value()
	{
		T value = default(T);
		Map(t =>
		{
			value = t;
			return (Monad)null;
		});
		return value;
	}

	public abstract Monad<U> Map<U>(Func<T, Monad<U>> lambda);
	public abstract void Complete(T t);
}

We can see that Value is a glue to just extract the value from the monad. It’s an unwrap operation.

Next, we have our identity monad:

public class Id : BaseMonad
{
	private T t;

	public override Monad<U> Map<U>(Func<T, Monad<U>> lambda)
	{
		lock (this) {
			while (t == null)
			{
				Monitor.Wait(this);
			}
		}

		return lambda(this.t);
	}

	public override void Complete(T t)
	{
		lock (this) {
			this.t = t;
			Monitor.PulseAll(this);
		}
	}
}

We have value, simple map operation waiting for the value to appear, and a callback to fill the monad. Notice how this is effectively a promise.

Now, async monad:

public class Async : BaseMonad
{
	private T t;
	private int current;

	public override Monad<U> Map<U>(Func<T, Monad<U>> lambda)
	{
		if (t == null)
		{
			this.current = MonadFiberAsync.current;
			byte b;
			MonadFiberAsync.readyToGo.TryRemove(this.current, out b);
			MonadFiberAsync.helper.Switch(0);
		}

		return lambda(this.t);
	}

	public override void Complete(T t)
	{
		this.t = t;
		MonadFiberAsync.readyToGo.TryAdd(this.current, 0);
	}
}

The only difference here is that we do the cooperative scheduling instead of just pausing the thread.

Now, we’d like to decide how to use these monads. For that we need to have builders which we’ll be able to replace in runtime (similar to synchronization context):

public abstract class Builder
{
	public abstract Monad Build();
}

public class IdBuilder : Builder
{
	public override Monad Build()
	{
		return new Id();
	}
}

public class AsyncBuilder : Builder
{
	public override Monad Build()
	{
		return new Async();
	}
}

No magic here. And the env:

public class ExecutionEnvironment
{
	public Builder SyncBuilder;
	public Builder AsyncBuilder;
}

If you think about task builders in C# (which let you return any task type) then you’re right.

Okay, let’s go with some operation now. Again, I’ll have 2 jobs:

private static void RunInternal()
{
	WhereAmI("Before nesting");

	var env = new ExecutionEnvironment
	{
		SyncBuilder = new IdBuilder(),
		AsyncBuilder = new AsyncBuilder()
	};

	RunInternalNested(env);

	WhereAmI("After nesting");
}

We create environment with builders and then continue:

private static void RunInternalNested(ExecutionEnvironment env)
{
	var start = env.SyncBuilder.Build();
	start.Complete(0);
	start.Map(i =>
	{
		WhereAmI("Before creating task");

		var delay = Delay(2000, env);

		WhereAmI("After creating delay");

		return delay;
	}).Map(i =>
	{
		WhereAmI("After sleeping");

		var data = Data("Some string", env);

		WhereAmI("After creating data");

		return data;
	}).Map(result => {
		WhereAmI($"After reading data {result}");

		return env.SyncBuilder.Build();
	});
}

We glue some lambdas together thanks to mapping. Notice how we return delay from the first lambda and then call Map on it which makes the waiting. Also, notice how I pass environment explicitly. In some other language we could pass it via implicits, or we could utilize compiler to do the reverse-coloring for us (to avoid parameters and lambdas!).

Moving on:

private static Monad Delay(int timeout, ExecutionEnvironment env)
{
        var a = env.AsyncBuilder.Build();
        var timer = new Timer(_ => a.Complete(new object()), null, timeout, Timeout.Infinite);
        GC.KeepAlive(timer);
	return a;
}

Instead of blocking the thread with sleep, we create a timer which calls the callback and resolves the monad.

private static Monad Data(string d, ExecutionEnvironment env)
{
	var monad = env.SyncBuilder.Build();
	monad.Complete(d);
	return monad;
}

Here we just return the data.

And another side job:

private static void SideJob()
{
	WhereAmI("Side job");
}

Output:

Thread 1 Time 7/23/2020 10:56:48 PM: Start - MonadFiberAsync
Thread 1 Time 7/23/2020 10:56:48 PM: Before nesting
Thread 1 Time 7/23/2020 10:56:48 PM: Before creating task
Thread 1 Time 7/23/2020 10:56:48 PM: After creating delay
Thread 1 Time 7/23/2020 10:56:48 PM: Side job
Thread 1 Time 7/23/2020 10:56:50 PM: After sleeping
Thread 1 Time 7/23/2020 10:56:50 PM: After creating data
Thread 1 Time 7/23/2020 10:56:50 PM: After reading data Some string
Thread 1 Time 7/23/2020 10:56:50 PM: After nesting
Thread 1 Time 7/23/2020 10:56:50 PM: End - MonadFiberAsync

Okay, works like a charm. However, let’s now do some magic. Instead of using async builder for async methods lets do AsyncBuilder = new IdBuilder(). Output:

Thread 1 Time 7/23/2020 10:57:23 PM: Start - MonadFiberAsync
Thread 1 Time 7/23/2020 10:57:23 PM: Before nesting
Thread 1 Time 7/23/2020 10:57:23 PM: Before creating task
Thread 1 Time 7/23/2020 10:57:23 PM: After creating delay
Thread 1 Time 7/23/2020 10:57:25 PM: After sleeping
Thread 1 Time 7/23/2020 10:57:25 PM: After creating data
Thread 1 Time 7/23/2020 10:57:25 PM: After reading data Some string
Thread 1 Time 7/23/2020 10:57:25 PM: After nesting
Thread 1 Time 7/23/2020 10:57:25 PM: Side job
Thread 1 Time 7/23/2020 10:57:25 PM: End - MonadFiberAsync

Notice that Side job waited until the first job finished and wasn’t run in the middle. The thread was sleeping since we blocked it by using synchronous monad. One line of code and we disabled asynchronous code.

Is this approach better? In theory this has the best of two worlds, you can wait synchronously for async code, not block the thread, and change the logic any way you like. Allocation is much higher, but that’s obvious with this approach. Also, there is a lot of plumbing code so we’d probably need a clever compiler doing the magic behind the scenes but that could bring us back to the C# solution. Apart from different coloring, I pass environment explicitly but once I stop doing that (and it’s added by the compiler) then it isn’t much different from thread local variables for synchronization context.

However, the difference now is that nothing can escape the monad (well, at least when we have compiler checking that) so we can control how things behave deep down. If we better encapsulate the environment then it won’t be possible to change the async machinery by replacing some global state.

Ultimately these solutions may not necessarily differ that much.