Why I Dislike Threads

Most people who have talked to me about programming, knows that I am not a big fan of threads, and advocate event driven programming. The reason for this is not so much that I like event driven architecture, but more that I dislike threads.

Threads break one of the fundamental principles in programming: Isolation. Having two or more execution threads in a process, means that they are no longer isolated memory wise. Threads can mess with data other threads data, which in turn can create inconsistent data, or just lead to crashes.

Additionally threads cannot be controlled. There is no way to stop or kill a runaway thread without dragging the entire process with it. And it does not even make sense to kill a thread because it can leave the process in an inconsistent state. This also makes it impossible to use the fork() call, as there is no way a process can be made deterministically when another execution thread is running. Processes are on the other hand well isolated and can be easily controlled.

Another issue with threads are that they are hard to keep simple. Often a program will start with a few locks here and there, but soon they will be split into more fine grained locks, and locking order will be imposed. This makes it difficult to change or expand a program, as not only new APIs have to be learned, but locking order as well.

Sometimes threads are necessary though. Kernels is a prime example (and is where threads was initially created for). When performing parallel computations and a big data set needs be read and updated continously, threads are more or less impossible to avoid. This however is relatively rare. The most common usage of threads is to handle blocking IO calls. Instead of using blocking IO it is possible to non-blocking IO. Unfortunately a program must be heavily modified to use this programming model, due to interleaving between IO calls. An example of interleaving IO frameworks is Twisted. While Twisted is great, it suffers from having to use deferreds which can make program flow complicated to figure out. This is also partly a problem with Python as the language does not support anonymous code blocks (only expressions are supported)

An alternative to the interleaving model is to use shared-nothing micro threads. In this model threads are created but they do not share memory, and must communicate through message parsing. This may sound similar to multi-process scheme, however micro threads exists only in user space, i.e., they are application level only. This means that context switching and message parsing can be made very fast. Two examples of such languages is Stackless Python and Erlang. In Erlang creating a new thread is basically a function call, and uses 300 bytes of memory.

Both Stackless and Erlang have very good mechanisms for sending messages. Serialization and serialization is completely transparent. This makes is much easier to split a program into several execution units compared to using processes as schemes for message parsing has to be constructed when using processes. Using micro threads retains "normal" program flow, which makes programs more intuitive to understand. By using micro threads it is also possible to parallelize the program as the micro threads can be executed independently. This is in big contrast to interleaving of IO, which is can be difficult to parallelize.

I guess it is not really threads I dislike, but shared memory. Joe, who is one of the persons that created Erlang, wrote a nice entry about this some ago: Why I don't like shared memory.

Event-driven or a micro thread based architecture is by no means a silver bullet though. In a recent conversation with Gerd we talked about solving a problem which in itself concurrent. In this case, using event-driven did not solve anything. In such cases it is necessary to either bite the bullet, or one will have to rethink the solution.

Found a New Criteria for Evaluating Technology

Whenever you are evaluating a new technology, ask yourself:

Which problems would be easier to using this technology?

If you cannot come with a good answer after understanding the core of the technology, you can probably stop reading.

How I Lost My Faith In Web Services

I used to loathe web services. I found it to overly complex and complicated for doing something that really isn't that complicated. However living in a grid world, it is hard to avoid web services, so I started looking into it. And I really, really tried to like it. And for while I think I liked it. However while trying to create a WSDL for a service, I realized, as others have, that things are not that simple. Web services appear to be in an infant state; as CORBA once was - only worse. There actually exists an organization which purpose is to create interoperability between the WS stacks and to remove ambiguous items in the standards.

Even the guy who created google web API agrees that web services suck. SOAP also pretty much ignores all HTTP error codes, throwing out a good error model, and usefull stuff such as redirection. There are already several hundreds well functioning HTTP clients and servers. Finding a client library that supports WSRF and whatnot brings down the number of clients to 5-10 options - perhaps even less. And their interoperability is by no means guarenteed, unless you use really simple stuff.

I am also questioning the whole reason to use web services in grid. The need for handling state and receiving notifications (to get an asynchronous system, where polling is not necessary) seem rather obivious to me. Yet they went for web services, which does neither of these. Instead they created WSRF and WS-Notification to model this on top. Now, I am all about minimal protocols and layering, but this is just crazy.

The opposite camp of WS is the REST people. However REST is really a design principle, and not a standard. Usually REST will use HTTP, URIs, and XML for its standards. Notice how it isn't inventing anything new and useless? REST, being a design principle, can be hard to understand as it might change the way you thinking (and we don't want that do we). Even the main grid guy does not understand it.

I find REST to be much better approach than WS. Mostly because it is more simple, yet more flexible - given that you understand HTTP. HTTP is in my opion very well designed, but unfortunately most people see HTTP as something which can only retrieve HTML pages. There is one problem with HTTP though: It doesn't do notifications. So, instead of inventing a beast similar to WS-notifcation, which in turn would require your client to run a server, is there a protocol which supports notifications, yet have the client acting as client? Furthermore it should be reasonable flexible and simple.

Such an animal already exists: XMPP does all of this. As a bonus it is already widely deployed, as it is the underlaying protocol of jabber. Yet it have managed to stay relatively hidden and staying of out of peoples way. I like such technologies; usually it means that just work. Everyone talks about WS these days, so clearly it is not working properly :-). Of couse, this Bill has already suggested using XMPP for grid, so what are waiting for?

Design by Committee sucks

I'm currently attendending 1st KnowARC Conference in Oslo. As I do not have a big group to discuss my research with (although I highly appreciate the discussions with my supervisor, it is also monoculture), it is important that I get out and collaborate. Also, the topic of my ph.d. study (grid data management) is a quite relevant topic these days.

Yesterday we had a meeting about capability and design on a furture grid data management system. However stuffing ~20 people into a room and let them discuss (only like five where active though) does not produce good results.

As it could be expected people have very different views on what the system should be able to do, and how it should be constructed. However instead of trying to create a reasonably well designed system, we ended up with pretty much the union of everything. This way no one really loses. Unfortunately no one really wins either. The system gets overly complex, and insanely hard to implement (we're talking distributed, fault tolerent, scalable systems). And usually no one will implement anything complete due to the complexity of the system.

Good design can created in many ways. But it does not come from committees which tries to solve everything at once.