[erlang-questions] Teaching Erlang as part of a paper -- advice sought

Ulf Wiger ulf.wiger@REDACTED
Mon Feb 8 10:33:23 CET 2010

Richard O'Keefe wrote:
> Here there is a dispute between me and one of the other lecturers
> in the department, who will not be involved in this paper, at least
> not this year.  I want the students to start learning about
> concurrent programming in a language in which data races (at least
> data races not involving external resources) are simply impossible.
> He thinks they should (a) learn what a data race looks like the hard
> way early on and (b) learn not be be afraid of data races, because
> the low level locking code on x86-64 Linux apparently has a benign
> data race.

Kostis has alreay mentioned that data races are possible in Erlang.

One possible benefit of using your approach is that it can highlight
that race conditions come in different forms. Some are part of the
problem domain (e.g. handshakes in peer-to-peer networks, credit
card transaction processing, session management in messaging systems
in general, etc.) while others are accidental - a consequence of the
chosen implementation technique. I would think that reasoning about
the high-level races provides an ample foundation for talking about
low-level data races. BTW, which mutual exclusion techniques
can not be illustrated in Erlang?

I've seen many examples of programmers trying to wish away races
by e.g. changing calls to casts, failing to recognize that they
simply made potential deadlocks etc. harder to diagnose.

The proper way to address race conditions, IMHO, is from the top
down, and if you start with a language that causes lots of
accidental complexity, chances are that you will end up covering
much less ground.

Ulf W
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd



Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.


More information about the erlang-questions mailing list