Painless multi processing with Retlang

Retlang is a very nice and extensible library for handling multithreading the Erlang way, which means the concept of message passing and was created by Mike Rettig.

There is also a library from the Microsoft Robotics team called CCR which has the same goal. I’ve looked for it some time ago, but i dose not like its actor invocation syntax which looks really stodgily.

So lets start with some basic structures.


A fiber is an queue where you can add actions that then where dequeued and executed on a different thread. What thread this is depends on the type of fiber. Fibers are also support scheduling of the added actions for later execution and for continues execution.

All fibers are guarantee to execute only one action at the same time, which is very different to what the .Net ThreadPool dose. This is an important behavior, since it guarantees that all objects are thread safe when they are shared by the same fiber.

The following fibers are available (version

  • ThreadFiber – creates one thread and use this for execution
  • PoolFiber – uses the .Net ThreadPool
  • SynchronousFiber – only for Unit Testing
  • FormFiber – executes the actions on the Windows.Forms message thread
  • DispatcherFiber – executes the action on the given WPF Dispatcher

The last two are make the UI synchronization dead simple, and i plan to write later about them.

The most time you should use the PoolFiber, since it automatically distributes the action over all available CPUs and so it scale very well. Mike Retting measured that here.

ThreadFibers are should be only used if the added actions are taking a long time to execute. The reason is very simple. The most applications are creating a lot of fibers in their lifetime, in example one for each service. So you would have a lot threads in memory which only waiting for actions.

You should not share fibers for the whole application! Since fibers are guarantee to execute only one action at the same time, you would create a bottleneck. An exception are the Form- and DispatcherFiber because they are anyway restricted to execute only one action at the same time.


Channels are very lightweight in Retlang. They dose not have any threading code, all they dose is to deliver a published message of only one type to all of its subscribers.

As someone who knows the concept of a service bus, my initial thinking was to create global Channel<object> and handle all messages with it. But this is a very bad idea, since it creates a single bottleneck, its ugly (all subscribers a of type object) and it is not what Retlang is designed for.

There are also two other types of channels. The QueueChannel delivers the published message only to the first available subscriber instead of all. And the RequestReplyChannel blocks the sender until the subscriber sends back the reply.

how the channels help in multithreading when they dose not provide any threading?

This is where the Fibers fit in. An subscriber has to specify on which fiber it wants to handle the message. 

var fiber = new PoolFiber();

var channel = new Channel<string>();

channel.Subscribe(fiber, message=>{ Console.WriteLine(message); });

channel.Publish("hallo Retlang");


And that it is. All the other classes and interfaces are manly base classes and allow some nice extension points.