aspose file tools*
The moose likes Threads and Synchronization and the fly likes Are java threads, real threads? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Are java threads, real threads?" Watch "Are java threads, real threads?" New topic
Author

Are java threads, real threads?

Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi all,
I know that java threads are mapped to the system level threads by JVM/OS (though there would be variation in doing this I guess)..BUT what I want to ask is,
- according to me threads will inherit the address space of the process where they were spawned from, right?
- but in Java when we create Thread object it doesnt inherit (not in terms of OO tho) any address space from the code it spawned from , right?
So, essentially Java threads cannot be used to given an example of threading right?
Please throw some light on these issues...
Regards
Maulin
David Weitzman
Ranch Hand

Joined: Jul 27, 2001
Posts: 1365
Java threads have their own execution context (stack and related goodies), but other then that they're sharing all the same resources (the heap and all that it contains). It doesn't get much more lightweight unless you use a stackless language.
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

You are technically correct. A java thread as defined by the JLS does not have to map to an OS level thread. In that case you would have what is called a Green Thread. Completely managed by JVM. Of course this was too slow, so optimizers started to use OS level threads more and more, mapping the java resources onto the OS resources.
Unfortunately they didnt stop there, and most current JVMs violate the JLS in the name of speed enhancement.
Nevertheless, a thread is a thread. A java thread is a thread, just in a different context. So it is indeed a perfect example of threading.
As for stack, the JLS does not put restrictions on the implementation of threads. Sun's JVM happens to use a heap and stack, but this does not have to be the case. I suspect some lighter VMs like embedded ones do not use heap/stack philosophy.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Unfortunately they didnt stop there, and most current JVMs violate the JLS in the name of speed enhancement.
How so?


"I'm not back." - Bill Harding, Twister
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi all,
this question arose as once, like 4-5 years back, when I was in CS bachelors final year some prof asked me "what is a thread, is there a difference b/w java threads and the os level thread". Now, if he meant just the "conceptual difference" then I would say "no" but otherwise as we know that its JVM dependent mapping of Java threads to OS threads so we can't say Java Thread= OS Thread for sure...or can say so atleast loosely.
Well, I guess I am getting some light on this...
Regards
Maulin
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Primarily its instruction reordering.
Also note that while double checked locking is supposed to be broken in java, passages in the JLS suggest it should work.
here is a paper http://www.cs.umd.edu/~pugh/java/broken.pdf
The paper calls the JMM broken because it says its too restrictive. Its not really broken, it just disallows a lot of common optimizations.
I believe the paper also cites some bug reports on Sun about JLS violations.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Originally posted by CL Gilbert:
here is a paper http://www.cs.umd.edu/~pugh/java/broken.pdf

That looks like an older paper. I'm not sure it matches current thinking, which mostly worries about the JMM being insufficiently restrictive regarding handling of volatile variables and such (and there has been a recommendation to change this). It's possible that the change in thinking has resulted from changes in interpretation of a couple of ambiguous phrases in the JMM spec (http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html).
I also think that section 2.2 of that paper makes an error. As Pugh notes earlier in the paper, the JMM deals with variables, not labels; a variable may have more than one label. The section 2.2 example deals with a case where p.x and q.x may be the same variable, or might be different variables, but I think he mistakenly assumes that we have to satisfy both cases at once when reaching his conclusion that the JMM is overly restrictive. In particular, it appears to me that if they are the same variable, the box labelled "load p/q.x" doesn't need to exist, since the variable has already been loaded in the earlier "load p.x" instruction, and if they are different, there is no required ordering between it and the "use p.x" instruction, which may be later. While it's true that a static compiler can't know whether they are the same variable at compile time, it's perfectly possible for the JVM or the threading subsystem to know whether they are the same variable at runtime, and select the appropriate option, neither of which individually disallows the optimization Pugh is worried about.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by CL Gilbert:
You are technically correct. A java thread as defined by the JLS does not have to map to an OS level thread. In that case you would have what is called a Green Thread. Completely managed by JVM. Of course this was too slow, so optimizers started to use OS level threads more and more, mapping the java resources onto the OS resources.
Unfortunately they didnt stop there, and most current JVMs violate the JLS in the name of speed enhancement.

OK, indeed "how so?"?
If the JLS says thread MAY NOT map to OS threads, many JVMs are in violation of the JLS (including Sun's own).
If the JLS says threads are NOT REQUIRED to map to map to OS threads, it's up to the JVM designer/programmer to decide whether to map them or not.
I've not checked the JLS but you write that it's not required, you don't write it's not permitted so please explain why JVM internally mapping Java threads to OS threads is in violation of the JLS?


42
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Jeroen Wenting:

I've not checked the JLS but you write that it's not required, you don't write it's not permitted so please explain why JVM internally mapping Java threads to OS threads is in violation of the JLS?

Where did I suggest that?
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Originally posted by Warren Dew:

That looks like an older paper. I'm not sure it matches current thinking, which mostly worries about the JMM being insufficiently restrictive regarding handling of volatile variables and such (and there has been a recommendation to change this). It's possible that the change in thinking has resulted from changes in interpretation of a couple of ambiguous phrases in the JMM spec (http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html).


The JLS is equally as old. It has not changed significantly. Nor has it changed to address these issues.

I also think that section 2.2 of that paper makes an error. As Pugh notes earlier in the paper, the JMM deals with variables, not labels; a variable may have more than one label.
I dont know what you mean by label. No two variables are ever the same. Two variables can point to the same data though.
After further review of the paper and the JLS, I understand you point. He does blur the lines a bit. For instance, if you have two variables that point to the same data. The interaction with one variable puts no constraints on how you may interact with the other. There is no forced ordering. I think that is the point you were making, and I agree.
abhishek shanker
Greenhorn

Joined: Dec 18, 2012
Posts: 7

Hi All,

When we say "java threads are mapped to the system level threads by JVM/OS" Do we mean that when this java thread executes, then it is actually OS thread that is executing the java code?

Sorry to ask such a basic question here.
abhishek shanker
Greenhorn

Joined: Dec 18, 2012
Posts: 7
No one knows here ???
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Are java threads, real threads?