6

It is obvious that OS scheduling/ threading algorithms have their impact on Java threads but

can we safely say that Threads are OS/machine dependant?

If this is the case then doesn't it make Java platform dependant?

Vikdor
  • 23,934
  • 10
  • 61
  • 84
Just_another_developer
  • 5,737
  • 12
  • 50
  • 83

3 Answers3

7

Yes, the details of the scheduling of threads in Java depends on the JVM implementation and (usually) on the OS implementation as well.

But the specifics of that scheduling is also not specified in the Java SE specification, only a selected few ground rules are specified.

This means that as long as the OS specific scheduling is conforming to those ground rules, it is also conforming to the JVM spec.

If your code depends on scheduling specifics that are not specified in the JVM spec, then it depends on implementation details and can not be expected to work everywhere.

That's pretty much the same situation as file I/O: if you hard-code paths and use a fixed directory separator, then you're working outside the spec and can not expect your code to work cross-platform.

Edit: The JVM implementation itself (i.e. the JRE) is platform dependent, of course. It provides the layer that allows pure Java programs to not care about the platform specifics. To achieve this, the JRE has to be paltform specific.

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • hmmm @Joachim please read my question once again I asked "can we safely say that Threads are OS/machine dependant? If this is the case then doesn't it make Java platform dependant?" ....... Another question just popped up (which is not actually thread related) .. I read JVM is platform oriented , does it mean whenever in future an OS developed/created, A new JVM will also be needed for that OS – Just_another_developer Nov 05 '12 at 10:03
  • 3
    @Sobia You are absolutely correct. JVM needs to be implemented for each platform individually because Java is designed from the bottom up to shield you away from platform specifics. JVM is that abstracting layer. – Marko Topolnik Nov 05 '12 at 10:04
  • 2
    Yes, Sobia: the Java JVM is *not* platform independent. Pure Java *programs* however, can be platform independent (as long as they don't depend on any implementation-defined behaviour). – Joachim Sauer Nov 05 '12 at 10:13
  • @Sobia: I think I answered both parts: yes, specific thread behaviour is OS/machine dependent; Yes, the JVM is OS/machine dependent; No; well-written Java programs are not OS/machine dependent. – Joachim Sauer Nov 05 '12 at 10:14
3

... Java will usually use native threads, but on some operating systems it uses so called "green threads", which the JVM handles itself and is executed by a single native thread.

You shouldn't have to worry about this. It is all handled by the JVM, and is invisible to the programmer. The only real difference I can think of is that on an implementation that uses green threads, there will be no performance gain from multi-threaded divide-and-conquer algorithms. However, the same lack of performance gain is true for implementations that use native threads, but run on a machine with a single core.

Excerpt from JVM & Java Threads Scheduling

Adam Arold
  • 29,285
  • 22
  • 112
  • 207
  • I can only name Solaris but I don't know if it is still the case. – Adam Arold Nov 05 '12 at 09:58
  • @stackmonster: no mainstream Java SE platform uses green threads these days. You *might* want to look into the Java ME VMs of some feature phones and find them there. – Joachim Sauer Nov 05 '12 at 09:59
  • Check out [this](http://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads) question. – Adam Arold Nov 05 '12 at 10:00
  • Not just that, using green threads implies abandoning the JIT compiler. Green threads can only be (sensibly) implemented in terms of interpreted bytecode. – Marko Topolnik Nov 05 '12 at 10:00
  • @MarkoTopolnik: why? I don't think so. You *could* create native code that has the necessary callbacks into the JVM. Granted, green threads + JIT compiler is a rare combination, but I don't see why they *can't* be combined. – Joachim Sauer Nov 05 '12 at 11:02
  • @JoachimSauer True, it is not theoretically impossible, but it is quite a bit more complicated. A JIT could put fixed "yield" points into the native code. With interpreted code, however, the level of control is much greater and the scheduler has a chance to decide what to do next at the start of each new instruction. – Marko Topolnik Nov 05 '12 at 11:12
  • You may move this discussion to chat. – Adam Arold Nov 05 '12 at 11:48
3

Even on the same platform, if you write unsafe multi-thread code, behavior can depend on the full configuration details, the rest of the machine load, and a lot of luck, as well as hardware and OS. An unsafe program can work apparently correctly one day, and fail the next on the same hardware with more-or-less the same workload.

If you write safe multi-thread code, code that depends only on what is promised in the Java Language Specification and the library APIs, the choice of platform can, of course, affect performance, but not whether it works functionally.

Patricia Shanahan
  • 25,849
  • 4
  • 38
  • 75