## Towards Hard Real-Time Erlang

Erlang's actor concurrency model is a good fit for a wide range of concurrent applications. One domain that would seem ideal is real-time control of concurrent physical processes. But as it stands right now Erlang is best suited for soft real-time applications - there's really nothing in the language or runtime geared towards hard real-time constraints. Towards Hard Real-Time Erlang talks about one piece of the puzzle: a hard real-time scheduler.

In the last decades faster and more powerful computers made possible to seriously take into account highâ€“level and functional programming languages also for nonâ€“academic projects. Haskell, Erlang, Oâ€™CAML have been effectively exploited in many application fields, demonstrating how highâ€“level languages can help in writing efficient, readable and almost bugâ€“free code, rapidly stealing the prominent position gained in many fields by OO languages such as Java and C++. One of the fields where lowâ€“level imperative languages are still preferred to functional programming is that of hard realâ€“time applications, since usually programmers (and managers) think that highâ€“level languages are really not able to cope with the complex and critical requirements of realâ€“time.

In this paper we propose an implementation of a hard realâ€“time scheduler entirely written in Erlang, and perfectly integrated with the Erlang BEAM emulator. Performance analysis show that the proposed solution is effective, precise and efficient, while remaining really simple to use as expected by Erlang programmers.

The paper closes with mentions of two more pieces of the puzzle.

Realâ€“time message passing will be introduced in a future version...

...

A solution to the unpredictable behaviour of garbage collection should be implemented before a really hard realâ€“time scheduling can be done in Erlang.

Besides the scheduler, message passing, and garbage collector, what else do you think is needed before Erlang or something like it is a viable alternative in this domain? Or is the actor model really not such a great fit?

*Edit: Based on a comment from renox added closing quotes about message passing and garbage collector and added message passing to the editorial question.

## Comment viewing options

### Time to become a

Time to become a contributing editor, don't you think?

### Sure

I'll give it a shot.

Welcome aboard!

### I'm honored

Thanks, I'm pleased to be in such great company. And I promise to use my new powers only for evil.

Is there a way to promote this post on Erlang to a story in the parallel/distributed department without copying?

### I promoted it to the home

I promoted it to the home page. Alas, promoting is a display attribute, the item remains a forum item and as such does not belong to any category.

### The answer is in the paper

[[ Besides the scheduler and garbage collector, what else do you think is needed before Erlang or something like it is a viable alternative in this domain? ]]

The answer is in the paper: real-time messaging is needed also, and they're working on it.

As an aside the 'rapidly stealing prominent position gained in many fields by OO languages such as Java and C++' part of the introduction made me laugh, rapid by which standard?
Not by mine!

### Oops

The answer is in the paper: real-time messaging is needed also, and they're working on it

I was typing too fast and forgot to include that. Thanks for catching it.

As an aside the 'rapidly stealing prominent position gained in many fields by OO languages such as Java and C++' part of the introduction made me laugh, rapid by which standard?

An unwritten rule seems to be that the introduction is held to a lower standard than the rest of the paper. If that was anywhere else in the paper you'd expect at least a citation to pass the buck to somebody else for making the claim. :-)

Still, the full quote is

Oâ€™CAML have been effectively exploited in many application
fields, demonstrating how highâ€“level languages can help in writing
efficient, readable and almost bugâ€“free code, rapidly stealing the
prominent position gained in many fields by OO languages such as
Java and C++.

With the success of OCaml in the financial industry and Erlang in telecom I don't think that's complete hyperbole.

### Reference counting

Could a language like Erlang be implemented using plain old reference counting for heap management? I don't know Erlang but it looks like you can't create cycles since it doesn't permit mutation. Wouldn't that be better than tracing garbage collectors, for real-time applications? (Sorry if this is slightly off-topic for a discussion on schedulers, but GC was mentioned in the paper).

### You don't need mutation to create cycles

Closures are enough (e.g. you have a function that returns a tuple that contains the function). I don't know much Erlang either, but I'd expect a similar situation there.

### You don't necessarily need

There's no need for cycles to allow functions to refer to themselves, eager language or not. You can for example lambda-lift recursive function bindings in a Scheme, and get something like:

(let* ((%x (lambda (%x ...)
(let ((x (lambda (...)
(%x %x ...))))
...)))
(x (lambda (...)
(%x %x ...))))
...)


The functions that only call (%x %x ...) are prime candidates for inlining. The main overhead compared to regular recursive bindings is then that of the lambda-lifted bindings (one additional argument per binding).