The June 12th On Threads piece got slashdotted (twenty thousand hits for a 2,300 word hard-tech piece, not bad), which provoked really interesting feedback from (among others) David Dagastine, Greg Wilson, and Ben Holm, along with pointers to some related work. All those pointers are worth following, and some of the points are worth a little more discussion.
Changing the Java Picture · David Dagastine’s Java Synchronization Optimizations is super-interesting; in the course of working on the next release of Java, they’re bearing down hard on synchronization costs. Basically, they are building run-time tricks which can eliminate unnecessary locks entirely, and make them way cheaper in the (vast majority of) uncontended cases.
This is good stuff, but David is too cautious to draw one obvious conclusion that came up in a telephone chat I had with him. Suppose their work pays off: that locking in Java becomes substantially, qualitatively, cheaper. In this case, there’s going to be a strong incentive to use synchronized APIs like Vector as opposed to unsynchronized ones like ArrayList. The reason is that if you use ArrayList because you want to go fast in a multithreaded environment and you just know that your app will never try to access that list from more than one thread, then someone who comes along later doing maintenance might stupidly throw in another thread and blow everything up. If you use Vector, you’re safe because it’s synchronized. And if it doesn’t cost much to post a lock that doesn’t get used, why wouldn’t you?
Well, one reason is that we don’t know how well the stuff that David’s talking about is going to work in practice, and we won’t until we get a chance to shake down some real live applications against real live CMT silicon. But stay tuned, because this is important.
One To Watch the Others? · Greg Wilson of Dr. Dobb’s, in Deja Parallel All Over Again, points out that We’ve Seen This Movie Before, and provides some valuable historical background. He offers an excellent criticism of my piece: I listed “Testing and Debugging” fifth in my laundry-list of things to worry about, as if it were just another aspect of the problem. Greg says “This is the only problem worth mentioning.” Don’t know if I’d go that far, but I agree that it’s the biggest, hottest, short-term problem.
Greg’s proposal—reserve one of the cores to spy on the others—sounds plausible, but he only gives it a few paragraphs’ worth of exposition. I’m prepared to be convinced, but we need to do some up-front analysis to figure out how this would actually work.
Not New At All · Over at “Bellyblog” (good name), Ben Holm argues that people in the embedded-systems space have been doing threads and concurrency for decades, and have a rich body of experience to draw on. He claims he can’t remember ever having a deadlock bug; I get ’em all the time in my multi-threaded Java stuff (if you’re willing to generalize “deadlock” to “boneheaded synchronization error that causes the system either to blow up or freeze”).
Ben makes a good case that we ought to be trying to seed our ranks with some of these longtime embedded-systems veterans. He does grant my point, though, that the unit-testing tools are distinguished by their absence.
Erlang? · From London, Adam Langley wrote to to argue that while Erlang may not be the complete answer for the CMT future, it has a good story to tell for unit testing. I’ll quote Adam:
You really should have another look at the Erlang style of message-passing actors for this sort of thing. I can recommend Armstrong’s talk at LL2 as a good intro to it[1]. I’m not working in Erlang at the moment, but in a similar system. In this I can write unittests which setup fake actors and script message exchanges in an expect like manner. Consider:
def Unittest(): y = fake_actor() x = actor_to_unittest() x <- your_network_handling_actor_is(y) x <- more_resources_request() # expect a message from x to y of the correct type: expect(x, y, broadcast_advertising_request) z = fake_actor() x <- advertising_reply(z)You can script any possible message sequence you like. In addition, timeouts are just another type of message and you can test what happens in the case of a timeout too.
It works well for me at least.
[1] http://ll2.ai.mit.edu/ “Concurrency Oriented Programming in Erlang (invited talk)”
Bad Dreams · Jon Pile wrote to tell me of the things that can bite you in the course of writing “big honkin’ five-nines massively threaded applications”, which is what he does for a living.
He’s down on Java, but hasn’t looked at it since JDK1.1.17, and I still think Java’s about the best I’ve worked with for practical multithreading. Jon laid out these vivid scenarios:
Consider a large-scale order exchange platform, like a stock exchange. Each stock offers atomic operations; let’s reduce it to just bid and offer. It turns out that order counts for fairness, so you have to serialize all transactions that attempt to touch one stock.
This is still a very MT-happy application, because there are thousands of clients accessing thousands of stocks at any given moment. Great, no serialization between stocks - massive parallelism, here I come!
One fly in the ointment: when the worst-case, king-hell burst comes, it is all hitting one stock.
Consider: Martha Stewart is arraigned; everyone suddenly needs to sell Martha Enterprises. All other activity ceases.
Now imagine something even worse; say you allow bid/offer on the outcome of a World Cup match (ahem, a bet).
Now imagine that Senegal scores a goal against France, and suddenly the favorite is no longer the favorite. A million customers all try to update their bets...
It’s still a hardcore MT system, but man that worst-case burst is keeping me awake at night.
X10: The Long Haul · I got a pointer to IBM Research’s X10 project from Jimmy Cerra. It’s big, as in really big; they want to solve the whole problem at the largest scale in the most general possible way. More power to ’em: it looks like a really fruitful research direction.
Is This Fun, Or What? · Stand by everyone, there may be more history than I realized, but this is going to be an exciting ride.
