Concurrent Programming SP3-2017
TDA383/DIT390
If you find any broken links on this page, please report them to the instructors by email, so that they can fix them!
The lectures themselves are the ultimate reference for the course topics. Nevertheless, we refer you to the official course textbook for additional details:
M. Ben-Ari: Principles of Concurrent and Distributed Programming, 2nd Edition, Addison-Wesley
An excellent resource for programmers new to Erlang, freely available as a web tutorial:
F. Hébert: Learn You Some Erlang for Great Good! A Beginner’s Guide, No Starch Press, 1st edition, 2013
An advanced, up-to-date discussion of multi-processor programming using Java, which also includes basic topics:
M. Herlihy and N. Shavit: The Art of Multiprocessor Programming, Morgan Kaufmann, 1st edition, 2012Another good introductory book on Erlang:
S. St. Laurent: Introducing Erlang, O’Reilly, 1st edition, 2013An in-depth presentation of Erlang, written by the language’s primary inventor:
Joe Armstrong: Programming Erlang: Software for a Concurrent World, Pragmatic Bookshelf, 2nd edition, 2013
If you are interested in the history of how computer scientists have developed techniques and models to handle concurrency, you find many references on this page from a previous edition of this course.
Oracle’s Java tutorial and in particular the section Concurrency It contains nice small examples as well. It is a part of Essential Java Classes that also contains nice information about Streams and exception handling.
If you want to know more about Java we also recommend the language specification. Chapter 17 deals with threads and locks. It contains very valuable information for anyone trying to write something concurrent in Java.
We do not talk much about memory models in this course, but it is a very important issue. For everyone using advanced concurrency features in Java, this FAQ on the current memory model in Java is a must read.
The Java Swing GUI framework has several problems in connection with multi-threaded programs. In a Swing program there is always one thread executing that is not visible in the user source code: the event-dispatching thread. This thread executes all code in event handlers (listeners), for example in actionPerformed, mouseClicked, etc. These event handlers typically update both program state and the GUI. Thus, it is essential that all user code that causes GUI updates executes in this thread to avoid race conditions, with different threads concurrently manipulating the GUI. One exception to this rule is the creation of the GUI at program startup, which is often done in the main thread. This is (almost) OK, as long as all the creation work is done before the GUI is realized (made visible on screen).
