User threads versus Daemon Threads

[Kaydell Leavitt]

I thought that I understood that there were two types of threads: 1) User threads, & 2) Daemon threads and that Daemon threads only exist to serve User threads and when all of the User threads are dead, the Daemon threads all die too.

I thought that user threads means UI threads, but I am doubting that now. I've learned that Swing is not thread-safe and so you put all of the UI method calls on one thread, so there is only one UI thread, but there can be multiple User threads.

It is a common misconception that Swing windows start a thread with a call to invokeLater(Runnable) or invokeAndWait(Runnable). Implementing Runnable gives us the idea that a thread is going to be created but its not. I believe that start() is never called. Only run() is called, so a new thread is not started.

Now my question is: I don't understand the difference between User threads and UI threads.

Kaydell

[Henry Wong]

Implementing Runnable gives us the idea that a thread is going to be created but its not. I believe that start() is never called. Only run() is called, so a new thread is not started.

What start() method? Runnable objects do not have a start() method. The swing utilities method causes the event dispatching thread to call the run() method of the Runnable object -- there is no start() method.

This is also true for executors. The executor's thread calls the runnable object's run() method.

Henry
[ June 06, 2007: Message edited by: Henry Wong ]

[Qunfeng Wang]

What do you mean by UI thread? Java provides a Event-Dispatch-Thread to paint the components and deal with the events invoked by the user(like press a button, close the window etc.). Is it your UI thread? It's not created by a user. I'm not sure if it's a daemon thread.

invokeLater(Runnable) or invokeAndWait(Runnable) just let the Runnable object run in Event-Dispatch-Thread.

[Kaydell Leavitt]

What do you mean by UI thread?

I meant Event-Dispatch-Thread. Does Swing and AWT both put together share a single Event-Dispatch-Thread?

I read that Swing is not thread-safe. So do you have to call invokeLater() or invoikeAndWait() for every AWT, Swing, and Java drawing method?

I think that I misunderstood when I thought that a "user-thread" was a "user-interface" thread. There is only one user-interface thread, the event-dispatch thread, right?

So I don't know what a "user thread" is. Is the main() thread a user thread? Threads are user-threads by default, right?

I don't understand why, if all user threads die, that all daemon threads are interrupted(?) and die too? There must be a good reason for it, I just don't know it.

Kaydell

[Nicholas Jordan]

Originally posted by Kaydell Leavitt:
I think that I misunderstood when I thought that a "user-thread" was a "user-interface" thread. There is only one user-interface thread, the event-dispatch thread, right?

So I don't know what a "user thread" is. Is the main() thread a user thread? Threads are user-threads by default, right?
.....
Kaydell

A Thread is an execution of the instructions described by the code one has written. the idea of Threads are user-threads by default makes a distinction that does not exist ( at the machine level or as it is run by JVM ), is is what the path of execution does - what you set it to do - that this idea of a user-thread / daemon-thread distinction finds it's basis.

If you have a thread that say, writes to the screen or draws a picture, then is is commonly called a user-thread. Say one has another thread that does a long, involved computation ... but does not write to the screen: that thread would normally be called a daemon thread, but it is no different in it's implementation by the machine.

[Peter Chase]

Originally posted by Nicholas Jordan:
If you have a thread that say, writes to the screen or draws a picture, then is is commonly called a user-thread. Say one has another thread that does a long, involved computation ... but does not write to the screen: that thread would normally be called a daemon thread, but it is no different in it's implementation by the machine.

Well, there is exactly one difference between daemon threads and non-daemon threads. The JVM will exit when all non-daemon threads have finished; it ignores daemon threads when deciding when to exit.

The terms "daemon" and "non-daemon" threads have a precise standardised meaning in Java, because they are part of the threading API. If you use these terms, any Java professional should know exactly what you mean.

The term "user thread" does not have a precise meaning. Some people think "user thread" is a synonym for "non-daemon thread", while others think a "user thread" is one involved in a graphical user interface. Note, however, that a lot of Java applications do not have a Java user interface; they may have a Web user interface or they may be background, server programs. If you use the term "user thread" in a conversation with new people, you'd better explain what it means to you.

[Pravin Jain]

So I don't know what a "user thread" is. Is the main() thread a user thread? Threads are user-threads by default, right?

Threads are not non-daemon(user) by default. The initial setting
of daemon/non-daemon is decided by the thread which creates it.
ie. if a daemon thread creates an instance of Thread the newly
created thread will be a daemon thread. Same things is also
done for ThreadGroup and priority settings.

An example for use of Daemon thread would be:
Say in your application you have a clock which
is displaying the current system time. This
updation is being done by a thread which could
be coded as a infinite loop waiting every second
before updating the time being displayed.
This thread does not require to hold the termination
of application, If all other threads in your
application have finished their job then this
thread should be terminated, so we would
like to have the clock updating thread to be a
daemon thread.

[Nicholas Jordan]

Peter Chase: If you use the term "user thread" in a conversation with new people, you'd better explain what it means to you.

That is what I did, though I missed it (by mentally replacing User threads) as you point out:

Any thread may be marked as a daemon thread. When code running in some thread creates a new Thread object, that new thread is initially marked as a daemon thread if and only if the creating thread is a daemon thread. A program can change whether or not a particular thread is a daemon thread by calling the setDaemon method in class Thread. The Java virtual machine initially starts up with a single nondaemon thread, which typically calls the method main of some class. The virtual machine may also create other daemon threads for internal purposes. The Java virtual machine exits when all nondaemon threads have terminated [url=http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19152](�2.17.9)[url].

There is no distinction between between User threads and UI threads, nor Daemon threads while they are being run: original poster: I thought that I understood that there were two types of threads: , and this is a common mis-conception .... but threads do not have 'types' - how do you suggest we thwart this common fabrication ?

[ Message edit: an example is docs that state "current thread relinquishes the lock on this object" , but one never writes code that does that, do they: {lock.release();// huh ?} ~ though it would be easier to me if one could: You are correct, I was letting my thoughts flow free-form ]
[ June 17, 2007: Message edited by: Nicholas Jordan ]