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 Java''''''Time source code. In fact, using Java''''''Time 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 ''Java''''''Time'' or ''Java''''''Real''''''Time''. 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