CODEWITHSUNDEEP
javamultithreading
Stefan
Stefan

Reputation: 1059

Difference between methods from Thread class and methods used with Thread.currentThread()?

I want to start with doc from method currentThread():

  • Returns a reference to the currently executing thread object.
  • @return the currently executing thread.

Now knowing this, it makes sense that methods such as join(), isAlive(), getName(), isInterrupted() etc. are called like this for example Thread.currentThread().join.

My question is how we don't need currentThread prefix to call methods such as sleep(), yield(), interrupted() etc? How can static call for example Thread.sleep() know exactly what thread instance are we 'targeting' when there is no instance?

Upvotes: 1

Views: 103

Answers (2)

Solomon Slow
Solomon Slow

Reputation: 27190

why is for example Thread.sleep() written and not Thread.currentThread().sleep()

Because sleep() is not something that one thread should be able to do to a different thread.

Thread.currentThread() returns a reference to an instance of the Thread class. It's a special instance from the caller's point of view (i.e., it happens to be the Thread that called the function,) but from the language point of view, there's nothing special about it at all. It's just a thread.

That means, if you can call Thread.currentThread().foo(), then you can call someOtherThread.foo().

Even if you were allowed to call someOtherThread.sleep(), it would be a very bad idea. That's why they made sleep() a static method that implicitly operates on the calling thread.

My question is how we don't need currentThread prefix ...

OK, this is just my two cents worth, but if you think of currentThread() as some kind of a prefix, then I would advise you to spend more time learning the basics of the Java language before you dive into writing multi-threaded programs.

Upvotes: 1

Cameron Skinner
Cameron Skinner

Reputation: 54386

How can static call for example Thread.sleep() know exactly what thread instance are we 'targeting' when there is no instance?

They target the currently executing thread.

From the docs for Thread:

Causes the currently executing thread to sleep

The documentation for yield and interrupted etc also mention that they affect the current thread.

Regarding the comments about join, getName etc:

It doesn't make sense to make join static. If you did, the only thread you could join would be the current thread, which would immediately deadlock. You would be asking the current thread to wait for itself. join has to be non-static so you can tell it which thread to wait for (OK, you could have static join(Thread threadToJoin) but that's pretty cumbersome).

Sleep, and yield only make sense statically - you would never tell another thread to sleep or yield (you don't know what the other thread is doing - it might not be in a sensible state to sleep or yield). You only ever want to put yourself to sleep.

The other methods you mention in the comments could conceivably have static variants, but it makes more sense for them to be non-static because they provide information about the specific Thread object they are called on. You may notice that interrupted and isInterrupted are static and non-static, respectively, so there are cases where it makes sense to provide both. Is it worth having a static getCurrentThreadName() method? Probably not. We don't look for thread names very often, but checking for interruption is a very common operation so the convenience of not having to say Thread.currentThread().isInterrupted() outweighs the cost of maintaining two methods.

Upvotes: 5

Related Questions