Home » forums » LtU Forum

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.

By James Iry at 2008-08-27 04:46 | LtU Forum | previous forum topic | next forum topic | other blogs | 8934 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Time to become a

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

By Ehud Lamm at Wed, 2008-08-27 04:57 | login or register to post comments

Sure

I'll give it a shot.

By James Iry at Wed, 2008-08-27 16:51 | login or register to post comments

Great

Great. See the link at the bottom of the FAQ to post home page items.

Welcome aboard!

By Ehud Lamm at Wed, 2008-08-27 17:52 | login or register to post comments

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?

By James Iry at Wed, 2008-08-27 18:36 | login or register to post comments

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.

By Ehud Lamm at Wed, 2008-08-27 18:58 | login or register to post comments

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!

By renox at Wed, 2008-08-27 09:10 | login or register to post comments

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

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++.

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

By James Iry at Wed, 2008-08-27 17:05 | login or register to post comments

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).

By Thomas Munro at Thu, 2008-08-28 09:52 | login or register to post comments

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.

By Matt M at Thu, 2008-08-28 12:47 | login or register to post comments

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).

By pkhuong at Thu, 2008-08-28 17:28 | login or register to post comments