Forums Register Login

currentThread?

+Pie Number of slices to send: Send


Pasted above is the code in my book. I get everything other than the while loop from the run() method. I know that thisThread is the current thread running, but I'm not quite what exactly that means. I'm also a bit confused about setting the runner thread to null (runner = null). I feel like my book doesn't do a great job of explaining how threads interact. Could someone please put the pieces together for me?
+Pie Number of slices to send: Send
 

Sky wrote: I know that thisThread is the current thread running, but I'm not quite what exactly that means.



To understand all these concepts, you have to first have a clear idea of how your code is compiled, into what is it compiled, how are methods loaded on the stack, what are threads of execution and what is a Java Thread , and how do they work, interact with each other.

Now, getting back to your query. Forget the code for now. Tell me, do you know what happens when you say java <class_name> in this case java LinkRotator? Can you tell me what happens when you fire this command? How does the execution of your byte code happen? Where does it start? What is main() or in this case what is init()? What does it do?
+Pie Number of slices to send: Send
I think this ought to go to our GUIs forum.

There is a serious problem; you are accessing Swing methods from a Thread other than the “EDT”. That is incorrect and error‑prone; and should never be done. You should access Swing methods only from the EDT. You can find out how to do that (and what EDT means) here.
+Pie Number of slices to send: Send
 

Earlier, I wrote: . . . you are accessing Swing methods from a Thread other than the “EDT”. . . .

I think you are, but am not sure. Please somebody, check whether I am mistaken.
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:
To understand all these concepts, you have to first have a clear idea of how your code is compiled, into what is it compiled, how are methods loaded on the stack, what are threads of execution and what is a Java Thread , and how do they work, interact with each other.

Now, getting back to your query. Forget the code for now. Tell me, do you know what happens when you say java <class_name> in this case java LinkRotator? Can you tell me what happens when you fire this command? How does the execution of your byte code happen? Where does it start? What is main() or in this case what is init()? What does it do?



Thanks for your response!

I'm a complete beginner at this, so, I'm guessing that when you say java LinkRotator, you are creating a class, which in this case, is a subclass of the Japplet class, making it an applet. The init() is the thing that starts once the Applet is created. The start() is also executed when the applet is first created. That's basically the extent of my knowledge, haha. I'm not quite sure what a byte code is? Help?!
+Pie Number of slices to send: Send
 

Campbell Ritchie wrote:I think this ought to go to our GUIs forum.

There is a serious problem; you are accessing Swing methods from a Thread other than the “EDT”. That is incorrect and error‑prone; and should never be done. You should access Swing methods only from the EDT. You can find out how to do that (and what EDT means) here.



Wow. That sounds intense. Hopefully I didn't break a law or something, haha! Uh...I appreciate your help, but is there any way you could possible translate that to english? I have no idea what that (or the link) means, haha
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:

Sky wrote: I know that thisThread is the current thread running, but I'm not quite what exactly that means.



To understand all these concepts, you have to first have a clear idea of how your code is compiled, into what is it compiled, how are methods loaded on the stack,



No, that's not relevant for understanding threads.

Now, getting back to your query. Forget the code for now. Tell me, do you know what happens when you say java <class_name> in this case java LinkRotator? Can you tell me what happens when you fire this command? How does the execution of your byte code happen? Where does it start? What is main() or in this case what is init()? What does it do?



This is also not relevant for understanding threads.
+Pie Number of slices to send: Send
Soooo...can anyone tell me what it means when the code compares runner = currentThread? And what it means when setting runner = null?
+Pie Number of slices to send: Send
 

Jeff Verdegan wrote: No, that's not relevant for understanding threads. ...... This is also not relevant for understanding threads.



Yes Jeff. I knew this before I wrote what I wrote. But why not start with the basics? Since he is quite new to all this, I thought it would be better if I explained this concept of "current thread" using analogy of how main() is loaded on to the stack and then how a new thread is spawned for each such execution. See his response:

Sky Wallen wrote: I'm a complete beginner at this, so, I'm guessing that when you say java LinkRotator, you are creating a class, which in this case, is a subclass of the Japplet class, making it an applet. The init() is the thing that starts once the Applet is created. The start() is also executed when the applet is first created. That's basically the extent of my knowledge, haha. I'm not quite sure what a byte code is?



That just confirms he is a complete novice. He is, in my opinion, asking the wrong questions (at least for now). He is directly going into threading and what not before even understanding the basics.

@ Sky : Now understand this carefully:

a) First of all, when you say javac <source_file_name>, your source code gets compiled in to a class file. This class file has the byte-code which the JVM will interpret at run time.

b) Next, when you fire java <class_name>, you are instructing the JVM to actually load your class into the virtual machine, and start its execution.

c) Now comes the use of main() method. This is the first method that is called whenever you fire the java <class_name> command. The JVM spawns a Thread which is called the main() Thread.

d) What you are asking is what is the "currentThread"? In Java language we have a concept of Thread. Now, at any given point of time during the execution cycle of your Java application, there is only 1 Java Thread running. Whichever Thread(with a capital T, and NOT a thread of execution) is running , that Thread is called the currentThread. It can be retrieved using the static method like you have done in your code.

Sky Wallen wrote:... I'm also a bit confused about setting the runner thread to null (runner = null)



This is simply a check to find out whether the there is already a Thread(again with a capital T) already spawned somewhere in the Runnable Pool which can be used to start() the applet() which is initialized using the init() method.

My advice to you is that for now, get your fundamentals about Java crystal clear. Forget Applets, Threading, SWING, AWT for now. First be thorough with the following topics:

1 Declarations and Access Control
2 Object Orientation
3 Assignments
4 Operators
5 Flow Control, Exceptions
6 Strings
7 Generics and Collections
8 Inner Classes
9 Threads


Study them in order. Study from Head first Java. As and when you have any doubts, revert back.







+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:

Jeff Verdegan wrote: No, that's not relevant for understanding threads. ...... This is also not relevant for understanding threads.



Yes Jeff. I knew this before I wrote what I wrote. But why not start with the basics?



It's not about starting with the basics. The problem is that you posted something that was false as if it were factually true. AND you introduced material that can only serve to cloud the matter. The points I addressed have no relevance to the OP's question.

d) Now, at any given point of time during the execution cycle of your Java application, there is only 1 Java Thread running.



Absolutely false.

+Pie Number of slices to send: Send
 

Jeff Verdegan wrote:

Mansukhdeep Thind wrote:

Jeff Verdegan wrote: No, that's not relevant for understanding threads. ...... This is also not relevant for understanding threads.



Yes Jeff. I knew this before I wrote what I wrote. But why not start with the basics?



It's not about starting with the basics. The problem is that you posted something that was false as if it were factually true. AND you introduced material that can only serve to cloud the matter. The points I addressed have no relevance to the OP's question.



OK.

Jeff Verdegan wrote:

Mansukhdeep Thind wrote:d) Now, at any given point of time during the execution cycle of your Java application, there is only 1 Java Thread running.



Absolutely false.



Isn't it the case that at any point only 1 Java Thread instance is running. Yes, there can be N Thread objects in the Runnable Pool. But the JVM thread scheduler choose only 1 Thread to run at a time. Right? It appears to us that there is simulataneous execution happening simply because the CPU does time slicing so quickly. Otherwise can 2 Thread objects run simultaneously in Java? I don't think so. Read this article Unless we have a multi-core processor, I don't think we can have simultaneous execution. Can we Jeff? Also, you only wrote a reply in this article only saying what I just said. We can have concurrent execution though.
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:Isn't it the case that at any point only 1 Java Thread instance is running.


No, that's not the case. At any given time multiple Java threads can be running, meaning they're inside their run method. Obviously, any given processor core will be executing the instructions that go with just a single Java thread at a particular point in time, but multiple Java threads will nonetheless be running from a Thread perspective.
+Pie Number of slices to send: Send
 

Ulf Dittmer wrote:

Mansukhdeep Thind wrote:Isn't it the case that at any point only 1 Java Thread instance is running.


No, that's not the case. At any given time multiple Java threads can be running, meaning they're inside their run method. Obviously, any given processor core will be executing the instructions that go with just a single Java thread at a particular point in time, but multiple Java threads will nonetheless be running from a Thread perspective.



Yes, they are running in the sense that they are all started. That is nothing but Concurrent Execution, not simultaneous. But at one instance of time, a single core processor can not execute more than 1 thread, be it even a Java Thread object. If I start 10 Java Thread instances one by one by calling the start() method, all will be scheduled to run and be placed in the Runnable Pool. BUT, only 1 will be picked at a time for execution or the run() method by the JVM according to the underlying architecture. Which one is executing at a particular point in time, we can find by using the Thread.currentThread() method. Simultaneous execution can not happen. Of course, if you go for a dual core or quadra-core processor, things change.
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:BUT, only 1 will be picked at a time for execution or the run() method by the JVM according to the underlying architecture.


That is where you're wrong. As I said, multiple threads can be inside their run method at the very same instance of time. That has nothing to do with whether their code is executed at that moment in time, and also nothing with how many cores or CPUs there are.
1
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:
Yes, they are running in the sense that they are all started. That is nothing but Concurrent Execution, not simultaneous. [i]But at one instance of time, a single core processor can not execute more than 1 thread,



Correct. But initially you didn't say the "single core processor" part. And that made your statement false.

But beyond that, as Ulf has already pointed out, for the question of "current thread," what's relevant is not if it is actually being executed by a CPU at this instant in time, but that is is a thread whose run() method has been started. Even on a single CPU, there could be 100 "current threads" at the same instant in wall clock time. At least 99 of them will have to be paused, but their PCs are all somewhere in the code executed by the run() method, and the notion of Thread.currentThread() logically applies. So even on a single core system, your statement is false.

Ultimately, the problem with that part of your explanation is that it's another red herring. The notion of "current thread" isn't affected by how many threads can be running simultaneously or concurrently. Introducing the "one thread at a time" part just added more misinformation, regardless of whether one takes the "concurrent" view or the "simultaenous" one.
+Pie Number of slices to send: Send
 

Ulf Dittmer wrote:

Mansukhdeep Thind wrote:BUT, only 1 will be picked at a time for execution or the run() method by the JVM according to the underlying architecture.


That is where you're wrong. As I said, multiple threads can be inside their run method at the very same instance of time. That has nothing to do with whether their code is executed at that moment in time, and also nothing with how many cores or CPUs there are.



Being inside their respective run() methods at the same instance of time means what? It means that they are a part of the runnable pool. Correct? Or that they are simultaneously being executed by the JVM scheduler? My understanding is that all of them are in runnable state. But only 1 out of them will be actually running. Is that not the case?
+Pie Number of slices to send: Send
 

Sky Wallen wrote:Soooo...can anyone tell me what it means when the code compares runner = currentThread? And what it means when setting runner = null?



Yes, I had also great difficulty in understanding this.

You mentioned a book. I believe it would not be a well-known book. Because, the code has many issues and does many things in a wrong manner.

From looking at the code, I understand that when the Applet starts to run, a Thread is started which simply increments the counter. When the button 'Go' is pressed, the thread was meant to be stopped. But, this is not the right way to do that (and that null check looks horrible to me).

The right way to gracefully stop a thread is to use interrupts. You can check this section from the tutorial to know more about that. Also, for the while loop, you should be looking to use a boolean variable to start with.
+Pie Number of slices to send: Send
 

Mansukhdeep Thind wrote:My understanding is that all of them are in runnable state. But only 1 out of them will be actually running. Is that not the case?


That is not the case, as has been stated repeatedly by now. Several threads will be running at the same time from the perspective of the JVM scheduler. Whether several threads are running (or could be running) at the same time from the perspective of the OS depends on the details of the underlying hardware.
+Pie Number of slices to send: Send
 

Ulf Dittmer wrote:

Mansukhdeep Thind wrote:My understanding is that all of them are in runnable state. But only 1 out of them will be actually running. Is that not the case?


That is not the case, as has been stated repeatedly by now. Several threads will be running at the same time from the perspective of the JVM scheduler. Whether several threads are running (or could be running) at the same time from the perspective of the OS depends on the details of the underlying hardware.



OK. So here is what I understand. We say several threads are running at the same time from the JVM's perspective simply if all of them have been started. It has nothing to do with which thread is actually being executed. Correct?

Jeff Verdegan wrote: At least 99 of them will have to be paused, but their PCs are all somewhere in the code executed by the run() method, and the notion of Thread.currentThread() logically applies. So even on a single core system, your statement is false.



I could not understand this statement Jeff. What do you mean when you say "but their PCs are all somewhere in the code executed by the run() method..."? What are PCs of threads?

Jeff Verdegan wrote: Ultimately, the problem with that part of your explanation is that it's another red herring. The notion of "current thread" isn't affected by how many threads can be running simultaneously or concurrently. Introducing the "one thread at a time" part just added more misinformation, regardless of whether one takes the "concurrent" view or the "simultaenous" one.



Perhaps my definition of current thread was flawed. I was confusing it with currently executing thread. Thanks for getting me on track.
+Pie Number of slices to send: Send
"Executed" is almost as fuzzy a term as "running" in this context. That's why I talked about JVM perspective and OS/CPU perspective.

PC = program counter, i.e. the pointer to the instruction currently being executed
+Pie Number of slices to send: Send
 

Ulf Dittmer wrote:"Executed" is almost as fuzzy a term as "running" in this context. That's why I talked about JVM perspective and OS/CPU perspective.

PC = program counter, i.e. the pointer to the instruction currently being executed




Thank you Ulf.
+Pie Number of slices to send: Send
How about a simpler question?

Which books do you guys recommend for me? and How long does it take to become decently proficient in java?

Oh, and what does runner = null do also?
+Pie Number of slices to send: Send
 

Sky Wallen wrote:How about a simpler question?

Which books do you guys recommend for me? and How long does it take to become decently proficient in java?

Oh, and what does runner = null do also?



If you are just starting off, I would recommend Head First Java by Kathy-Bert. Follow this link. Pretty well written book and very well illustrated. Devote an hour or 2 on a daily basis understanding the fundamentals of the language. It all depends on you how well/fast you grasp things.

Setting runner = null or any reference in Java to null simply means that now that reference is not pointing to any Thread object.
+Pie Number of slices to send: Send
 

Sky Wallen wrote:Oh, and what does runner = null do also?



Not sure if you missed my reply above to your question. Did you check on the interrupts link I provided?

As like other variables, runner=null simply loses the reference to the Runnable object and makes it eligible for GC. However, in this case since this Runnable object is still used by the Thread. And, this null logic is used in the code to break out of the while loop.
Barry's not gonna like this. Barry's not gonna like this one bit. What is Barry's deal with tiny ads?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 1432 times.
Similar Threads
Images don't appear in Swing code
Add image to JPanel
Scroller Applet & NS4 - getsize() method error
Phasor applet-some prbs already compiled code written here
using JFrame with KeyListener Interface and using paint method
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 09:02:36.