Slashdot Mirror

From the looks of things, C.A.R. Hoare's Communicating Sequential Processes (yes, the same guy who invented Quicksort). Well, Professor Hoare presently works at Microsoft Research, so I guess he may have more than passing involvement in the project. It's the basis for many other concurrent programming languages such as Occam, Erlang, and Limbo to name a few.

In its full generality, multithreading is an incredibly complex and error-prone technique, not to be recommended in any but the smallest programs. In excuse, we may plead that it was invented before the days of structured programming, when even FORTRAN was still considered to be a high-level programming language!

Parallel programming doesn't have to be quite as painful as it currently is. The catch is that you have to face the fact that you can't go on thinking with a sequential paradigm and have some tool, library, or methodology magically make everything work. And now, I'm not talking about functional programming. Functional programming is great, and has a lot going for it, but solving concurrent programming issues is not one of those things. Functional programming deals with concurrency issues by simply avoiding them. For problems that have no state and can be coded purely functionally this is fine, but for a large number of problems you end up either tainting the purity of your functions, or wrapping things up in monads which end up having the same concurrency issues all over again. It does have the benefit that you can isolate the state, and code that doesn't need it is fine, but it doesn't solve the issue of concurrent programming.

No, the different sorts of paradigms I'm talking about no shared state, message passing concurrency models ala CSP and pi Calculus and the Actor Model. That sort of approach in terms of how to think about the problem shows up in languages like Erlang, and Oz which handle concurrency well. The aim here is to make message passing and threads lightweight and integrated right into the language. You think in terms actors passing data, and the language supports you in thinking this way. Personally I'm rather fond of SCOOP for Eiffel which elegantly integrates this idea into OO paradigms (an object making a method call is, ostensibly, passing a message after all). That's still research work though (only available as a preprocessor and library, with promises of eventually integrating it into the compiler). At least it makes thinking about concurrency easier, while still staying somewhat close more traditional paradigms (it's well worth having a look at if you've never heard of it).

The reality, however, is that these new languages which provide the newer and better paradigms for thinking and reasoning about concurrent code, just aren't going to get developer uptake. Programmers are too conservative and too wedded to their C, C++, and Java to step off and think as differently as the solution really requires. No, what I expect we'll get is kluginess retrofitted on to existing languages in a slipshod way that sort of work, in as much as it is an improvement over previous concurrent programming in that language, but doesn't really make the leap required to make the problem truly significantly easier.

Home builders have architectural plans. Machinist have blueprints. Electronic equipment builders have schematics. Software specifications are uniformly deplorable.

Debugging multithreaded code can be relatively easy, you just have to start off on the right foot. The best way to do that is to leave behind older concurrency models like monitors with mutexes, which the inventor of that model rejected back in the 80s and go with more recent concurrency models like CSP (the newer way to do concurrency from the man who brought you monitors). From a more modern perspective like CSP reasoning about concurrency is a lot easier, and hence debugging becomes much simpler. In fact tere are model checking tools that can verify lack of deadlocks etc. The downside is that its much easier if you have a language that supports the model, or get an addon library to do it for you. You can get a CSP add-ons for Java: JCSP, and for C++: C++CSP. Alternatively languages like Eiffel, Erlang, Occam, and Oz, offer more of hat you need out of the box - concurrent programming with those languages is easy to get right. Changing languages is, of course, not an option for most people.

Right now, something worth getting good at is understanding how to write highly parallel programs that are reliable. Write something that has lots of intercommunicating threads and be confident the locking is correct. There aren't that many people who consistently get that right.

Interesting class. Looks pretty standard for a US/Canada education.

No, in fact I mean CSP - see http://www.usingcsp.com/

Have a look at yaws: http://yaws.hyber.org/ a high performance webserver written in Erlang.

At the OS level, a decent scheduler and not using giant locking will get you most of the way.

To get the most out of it though, the applications need to be multi-threaded and multi-threaded programming in (standard) C/C++ is not straight forward, in fact it can be almost downright impossible to debug.

Other programming languages are much more suited to multi threaded programming, particularly those that use the CSP model.

Construction of Concurrent Systems Software
http://www.herpolhode.com/rob/lec1.pdf
http://www.herpolhode.com/rob/lec3.pdf
http://www.herpolhode.com/rob/lec5.pdf

My favourite, of course, is Limbo but I only know of one environment where that is implemented : Inferno

here's another discussion on a similar theme

http://it.slashdot.org/comments.pl?sid=164547&cid= 13736089

You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things. Not to mention that Java's implementation of monitors is known to be broken (or at least was - maybe they've fixed it now?).

Doug Lea's util.concurrent package (now part of Java 1.5) certainly helps things on the Java front, but it's hardly a panacaea. Depending on the application, you may want to take a look at JCSP instead - it provides for an almost direct translation of ideas from Tony Hoare's CSP into Java. For languages with good concurrency support out of the box, you might try Erlang, Ada, Mozart/Oz, E, or Eiffel.

The "D" name is misleading: it has absolutely nothing to do with the creators of B or C at Bell Labs. The successor of C was Alef(the first latter of a different alphabet) which was used for the original edition of Plan 9[1], and a later descendant by the same team was Limbo(Introduction paper by no other than Dennis M. Ritchie) for the Inferno.

Both Alef and Limbo are much more interesting languages than "D", they keep the clarity and simplicity of C while providing a high level framework for concurrent systems. The only other language with a good concurrency model I know of is Erlang which is quite different but also very interesting and sadly rather under valuated.

uriel

[1] To avoid having to maintain Alef compilers for many architectures Plan 9 is ported to, it was replaced with a C library, libthread, that provides the same concurrency model, for high level programming Limbo replaced it. Libthread, despite it's name is completely different from other threading models and uses CSP to handle concurrency while avoiding locks and many other problems with traditional "threading" systems. Libthread is part of Plan 9 from User Space so you can use it in "legacy" Unix/Linux/BSD systems too(of course Inferno runs on all those systems too...)

The point of using Stackless Python (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets and channels. If your game engine works by creating actors as threads then using a scripting language that has a simple to use, efficient, and platform independent threading model is likely of great importance, and Stackless Python offers that.

If you're generally interested in better threading models, and being able to think and reason about threads and their interactions more easily then you really ought to check out CSP. Multithreading is actually easy if you do it right - it's just that most languages don't.

Jedidiah.

Three good places to start to get the core theory down (after which the practicalities are much easier to learn) are Applications of Process Algebra, Communication and Concurrency, and finally Communicating Sequential Processes which is available for free (the link is to a PDF of the book).

Jedidiah.

You might start here. Lots of other books will tell you how to use semaphores and mutexes. This book will help you to understand why to use semaphores and mutexes (and perhaps open your eyes to better concurrency constructs), and teach you how to reason about your multithreaded design so that you won't get any nasty surprises when it comes time to run it.

You mean like CSP that has been around for 20 years?

Both Inferno and Plan 9 allow CSP-style concurrent programming, and it's pure joy.

uriel

The key advantage that CSP has is that it is a real, live, honest-to-god mathematical theory of concurrency, which means that the primitives and composite operators have extremely well-defined semantics, and have been analyzed to ensure that they compose correctly. Plus, you can express a design intended for a language that supports CSP-style concurrency directly in CSP notation, and then analyze it using various tools (or even pencil and paper) to ensure that it is deadlock-free, and maintains whatever properties you want maintained.

If you are a Java programmer, you may want to check out the JCSP library of CSP primitives for Java. IMHO much easier to use than Java's native concurrency model.

Concurrency isn't the problem - the threads model is. The CSP style of concurrency reduces the number of difficult to reproduce bugs, and make those bugs that remain aenable to mathematical analysis to determine their cause and solution.

A good grasp of CSP theory makes concurrent programming much easier, and allows concurrent systems to be engineered mathematically, instead of just hacked together.

Heck, even trivial programs have real problems with this. And why is that? Because we have problems thinking in parallell all the time.

Exactly. So what we need is a way of thinking about the problem that makes it easy to think about and do analysis. I'm sure there are probably some Computer Science researchers contemplating these problems. Hopefully there are really good people, like Tony Hoare working on it. What's that? He did work on this already? He came up with something that solves most of these problems already? Can't have been that long ago could it? Only 20 years ago you say?

Check out CSP. If you want a way to think about multithreaded applications that makes managing threads and avoiding deadlocks easy it's already available - it just hasn't got the publicity amongst developers that it deserves. If your project is in Java there are already things like JCSP which let you do CSP style threading in Java right now.

Jedidiah.

This is what it means for me: http://www.cs.bell-labs.com/who/rsc/thread/

Also see Brian W. Kernighan's "A Descent into Limbo" and Dennis M. Ritchie's "The Limbo Programming Language".

And of course Hoare's classic: Communicating Sequential Processes.

Now you can enjoy the power and beauty of the CSP model in Linux and other Unixes thanks to plan9port including libthread and Inferno; yes, it's all Open Source.

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

My own personal recommendation would be the original book on CSP (it is an expanded paper essentially), an idea that is well worth-while, and also look at some of the useful applications

Is this book really as authoratitive as it tries to appear?