Java Platform Dependent Threading Discussion

Sure it is. Just add threads.

Do you mean when one uses NativeJavaThreads? The GreenJavaThreads are PlatformIndependent?. Personally, I haven't had many problems even using native threads with Java. Certainly, much less than going between WinThreads? and Pthreads in CeePlusPlus. At least notification is consistent in Java.

The problem appears to be that some people have been programming Java threads assuming PreemptiveMultiThreading? when you can only make the weaker assumption of CooperativeMultitasking?. While some VMs are more powerful, that doesn't imply that Java guarantees that power. On the other hand, somes others have been assuming that the threading is determinstic, whereas Java does not make that guarantee either. DeterministicThreading? is a quirk of certain VMs only. So, to summarize, people have been Java's threading model is stronger than it guarantees and hence landing in trouble. Similar problems happen in C, the world's most portable language, so this isn't enough to complain about Java. -- SunirShah

Are there any examples of problems caused by differing behaviour of threads on different platforms ? -- ChanningWalton

Yes. Take a program running a reader/writer thread pair that works fine in the Windows JVM, which has interleaved threading. Move it to another platform which doesn't. Thread starvation. Solution: Break up your thread processing (in the run method) into smaller chunks and call yield() at the end of a loop iteration if necessary.

I'm not sure I understand, I just tried two reader/writer threads using a single channel (ala CSP) and it seemed to work fine both on NT and Linux. -- RobertDiFalco

MacOS 9 and earlier is most likely to give you threading problems, because the simulation of PreemptiveThreading? in MRJ (the Macintosh Runtime for Java) depends on cooperative threading pervasive in that operating system. I've seen some interesting things happen using JNI, TCP/IP communication between a Java application and a non-Java application, etc... -- KeithRay

Green threads or native? [Both, green on Linux, Native on NT] http://wotug.ukc.ac.uk/parallel/groups/wotug/java/discussion/3.html http://www.jguru.com/jguru/faq/view.jsp?EID=47379

I'm not sure about these references. The first seems to be pushing Hoare's CSP channel approach instead of the Hoare earlier work on monitors, as is used in Java. The second seems to say that starvation is possible if you use poor threading logic. I agree with both of these. However, neither of them seem to suggest that there is some unavoidable starvation when using Java monitors in Green and Native environments. In fact, the Dining Philosophers example in the first reference can be easily programmed in Java (green & native) to work without starvation. Just my US.02 worth. Everyone who is unclear on these issues should take a look at the second edition of DougLea's Concurrent Programming In Java or even AllenHolub's Taming Java Threads. Both have examples of lock queues that prevent starvation when notifying waiters. -- RobertDiFalco

I must have not been clear. I do a lot of Java programming myself, so I have not bias against it. Yes there are ways you should do thread programming in Java to get correct behavior. However, doing what appears to be the simplest thing on NT and assuming you are going to get preemptive behavior between threads will jump up and bite you hard when you move to other implementations that don't give you the same behavior. Strictly speaking you should be paying more attention when you are programming in threads both because they are hard and because the Java spec doesn't define how threads are scheduled, so you know in advance you can not count on a specific behavior

Interesting point to consider here: would it be possible/desirable to equip Java (or some other language/development environment) with a -lcd option, say, which would _fail_ to run code if that code would fail on any Java-supported platform?

How about an example. I am doing some work at the moment for which concurrency must be designed for carefully. The application is being developed under NT and deployed on Solaris so anything that will help me avoid problems would be much appreciated. -- ChanningWalton

If you have periodically recurring tasks, I'd suggest you not relying on the system's native scheduler. For example, you may want to write your own EarliestDeadlineFirst? or RateMonotonic? real-time executive much like that in the JavaTime source code. In fact, using JavaTime is an alternative, as it has complete source and its Task class has the same interface and semantics as a Java Thread class. Just do a search on something like Google for JavaTime or JavaRealTime. Also, you probably know this, but do not rely on the order in which multiple waiting objects will be released when you call notifyAll. If you need an order, use something like a Mutex or Semaphore class with a blocking queue. Then, just do a notify (e.g. NOT notifyAll) on the queue, and release the objects using the method you prefer (i.e. FIFO, LIFO, priortized, etc). All of these techniques really help platform threading issues. -- RobertDiFalco

Woops, one more thing. If it will only be released on Solaris and NT, you might be okay as the latest JVM's allow you to use the native kernel threads on Solaris (as well as NT). If you knew this to be a static fact, you could then rely on the behavior of priorities. (Of course, you still couldn't be certain of the release order after an notifyAll). -- rad

Thanks, I'll check this out -- ChanningWalton

CategoryJavaPlatform