Multi-threaded Programming Makes You Crazy?

gduranceau writes "Help! My program deadlocks! I got several concurrent threads that write the same variable! Everything goes well on my mono processor but becomes an incredible mess on that 16 CPU monster! And of course, as soon as I add traces, problems disappear... Don't panic! Calm down and take a deep breath. "

Comments

Use the right tool

[AKAImBatman]

And of course, as soon as I add traces, problems disappear... Don't panic! Calm down and take a deep breathe...

...and get yourself a technology designed for multi-threaded programming. Java will give each thread its own cache of variables to prevent deadlocking on concurrent modifications. If you need to do something that requires more than one statement (thus creating a race condition), then you need to create yourself a semaphore-based lock:

synchronized(objectToModify)
{
    if(objectToModify.getX() == myObj.getX()) objectToModify.setY(myObj.getY());
}

Of course, such synchronizations can carry a huge penalty on multi-CPU systems. i.e. If you manage to stop every CPU, you could be wasting MASSIVE amounts of CPU time. As a result, you should always strive to push locks down as far in the code as possible. They must execute extremely quickly, and should only be called when absolutely necessary. Follow those guidelines and you'll find it fairly easy to write multi-threaded code.

Oh wait. I was supposed to praise the NPTL tool, wasn't I. Um... well... it's very nice. And they've got... um... penguins on the homepage. Oh, and look! It's GPLed! Wow. Just... um... wow. Hey, did you know that the author of Minix wrote a book on OS Design? Really. It even covers the basics of multi-threading. It's pretty cool, you should... um... check it out. Yeah, that's the ticket!

Re:Use the right tool

[LnxAddct]

Woah now, slow down there. I'm a big fan of python, but also a fan of Java. Java's JVM is on par with the size of Python. Java's redistributables, in particular with the new pak200, can easily be around 2 megs in size. Python is ridiculously slow, but still faster than ruby. I've done a ton of coding in both languages and there are plenty of cases where "Java is the solution" because no other platform provides its capabilities. Python's libraries also are laughable in comparison to Java's. Java has defined standards, a great set of APIs (granted the gui sucks, but the api is wonderful), and the only major complaint I even hear from people is about Swing. Swing in the upcoming java JVM is finally fully threaded and just about all of the problems people complained about are fixed (including pretty good support for native themeing). Java is a very nice language, but it is alot more. It is an entire platform and it has a set of tools that just don't exist with any other language. It is very well designed, speed hasn't been a concern for ages, modern jvms might run a few percent slower than native performance... but it's still (depending on what benchmarks you use) around 1000 times faster than python. You're right that if you need high performance, you don't necessarily use java (although modern jvms are fast enough that they are used in some cases), but if you're writing a program that does a fairly common task of say walking through a directory tree of a couple hundred thousand files... the user will notice the couple of seconds that it takes python... but java will seem much snappier. Both languages have their place, but until python gets a hell of alot faster, a better standard set of libraries, and more enterprise tools, you can't even really compare them... they are for entirely different needs. And far as memory goes, Python can be just as big of a bitch about it as Java can be.
Regards,
Steve

Re:Use the right tool

[slamb]

volatile - causes a read or write out to main memory, ie, not the local CPU cache.

Not even that, actually.

In C, it tells the compiler that the read or write to memory can't be reordered. If you do a read, it has to get it from memory right then, rather than reusing one from before that it might have stuck in a register. It doesn't tell the CPU anything about synchronizing its cache or executing the instruction in order, however. You've gotta have both.

In Java, it actually depends on the version of the language. third edition (Java 1.5, I believe). second edition (the first is the same; so Java 1.1-1.4). It appears to say what you said, but I don't buy it. Look at this article by a bunch of Java synchronization experts on double-checked locking. In particular, this sentence:

The consensus proposal extends the semantics for volatile so that the system will not allow a write of a volatile to be reordered with respect to any previous read or write, and a read of a volatile cannot be reordered with respect to any following read or write.

This change might have made it into the third edition. The second and first read like it provides this guarantee, but if these guys say not, then I'm not going to be depending on that without reading all of the chapter on thread interactions (not just the one section on volatile), reading everything they say, and doing some experiments. If that means my software runs 0.5% slower because I have more synchronization overhead than I need, then so be it.

Probably going to download it anyway...

[19thNervousBreakdown]

Looking at the list of functions that it hooks into, I don't see pthread_rwlock*. Are the pthread_rwlock functions implemented using other pthread_* funcs? I haven't run into any problems yet with the project I'm working on, but it would be nice to run through this and make sure everything's working as expected.

Re:Here's your problem...

[sakti]

Realized that link wasn't as helpful as I remembered. But here are some other good general links that should get you going.

http://en.wikipedia.org/wiki/Concurrent_computing
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/Actor_model

The E lang has some good documentation on concurrency, even if you don't use it.
http://www.erights.org/elib/concurrency/

As does Erlang.
http://www.erlang.org/download/erlang-book-part1.p df

How Ironic....

[valdis]

Slashdot reported the summary line thusly:

Developers: Multi-threaded Programming Makes You Crazy? 79 of 78 comments

What's wrong with this picture?

Re:Java no panacea -- must know what you're doing

[try_anything]

First, the compiler may reorder things.... The compiler may choose.... Compilers take care.... Even if the compiler doesn't reorder like that, though, the processor might.... the memory management unit *also* reorders writes.... I think it's the concept that's hard.

None of these things are given; there's no such thing as "the concept." The designer of the language decides what guarantees to give the programmer and what latitude to give to the compiler, as well as what structures are provided to manage concurrency. Essentially, the language designer decides what concepts the users of the language must understand and employ. C and C++ expose the programmer to the full complexity of machine behavior because efficiency has always been their overriding concern, and in any case, those decisions were made at a time when threading was a niche concern. Newer languages typically strike a different balance between efficiency and support for concurrency.