Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

comp.lang.c++.moderated on Java threads  RSS feed

 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Multithreaded programming: is the C++ standardization committee listening?

See this post

Alexei Alexandrescu is the author of Modern C++ Design.

[EJFH: Edited link so it didn't mess up the formatting of this page.]
[ August 19, 2004: Message edited by: Ernest Friedman-Hill ]
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looks to me like Alexandrescu should be using Java instead of C++.

C++ has very sound reasons for delegating threading to platform specific libraries. One of the key reasons is that probably the most important purpose of C++ is as a systems programming language - one in which one would implement a threading system for other applications to use.

For that matter, Java's "lowest common denominator" approach to threads arguably demonstates that incorporating threading into the language was a mistake. By not taking a stand on issues like cache coherency, multithreaded Java code loses the "write once, run anywhere" advantage that Java is supposed to have: code written and tested on a single processor system may run fine on a multiprocessor system with hardware cache coherency, but may die horribly on a multiprocessor system without it.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Warren Dew:
For that matter, Java's "lowest common denominator" approach to threads arguably demonstates that incorporating threading into the language was a mistake. By not taking a stand on issues like cache coherency, multithreaded Java code loses the "write once, run anywhere" advantage that Java is supposed to have: code written and tested on a single processor system may run fine on a multiprocessor system with hardware cache coherency, but may die horribly on a multiprocessor system without it.


Not sure that I agree with that.

If one does not make any assumptions about threading, apart from the ones guaranteed by the Java specs, then you're OK on all platforms, aren't you? At least, unless the Java on the platform is broken.

Java does not guarantee that code that makes unsafe assumptions, implicitly or explicitly, will run nicely on all platforms. If your code makes assumptions about cache consistency that aren't in the specs, all bets are off.

It's rather like saying that Java should be immune to differences in execution speed between different machines. If you write code that depends, implicitly or explicitly, on execution speed, it will work right on some machines and not on others. But that would not be the fault of the language.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter Chase:

Not sure that I agree with that.

Not sure I do, either - it's somewhat of a devil's advocate viewpoint. I think the position can be reasonably argued - thus "arguably" - but I'm undecided on whether I agree with that argument.

If one does not make any assumptions about threading, apart from the ones guaranteed by the Java specs, then you're OK on all platforms, aren't you? At least, unless the Java on the platform is broken.

You could say that, yes. On the other hand, "not making any assumptions" sometimes requires fairly complex code, code that is likely to be buggy until tested. That means you can't actually ensure that your code "doesn't make any assumptions" without testing it on all platforms - which loses the advantages of "write once, run anywhere".

It's interesting to note that early JavaRanch threads on this subject talked about all the Java virtual machines being "broken". It wasn't until later that it became clear that they weren't "broken" by the the JVM implementors' reading of the Java language specification; the specifications were (and are) not perfectly unambiguous, and the Java programmers were interpreting them in a way that would make writing programs easier, while the JVM implementors were interpreting them in a way that would make writing JVMs easier. The latter view prevailed.

Java does not guarantee that code that makes unsafe assumptions, implicitly or explicitly, will run nicely on all platforms. If your code makes assumptions about cache consistency that aren't in the specs, all bets are off.

In other ways, though, the Java language tries to make it easier to make safe assumptions, even if it means a performance hit on some platforms. In threading, it makes it difficult to make safe assumptions. The "no cache coherency" assumption - along with some other limitations, like the lack of synchronized constructors - is so loose that it's as if Java had left it up to the platform as to whether to use ones complements or twos complements for integer arithmetic. In practice, this means the onus is left on the programmer to write perfect code.

Specifying that twos complement must always be used, as Java does, even though it means a performance hit on ones complement machines, makes programming arithmetic code far easier, because the related bugs can be reproduced on any platform, rather than being platform dependent.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!