[SOLVED] should I run my Timer as a daemon?

I am using a Timer to compare the efficeincy of some algorithms and draw graphs of their relative performance across a range of inputs. Anyway needless to say I would like my Timer to be as light weight as possible, especially for the less processor intensive tasks so that there is a minimum of insertion error. I notice on the java Timer API there is an option in a constructor to run my Timer as a daemon. I know what daemons are in the context of system software and the API has this to say on the subject:

"By default, the task execution thread does not run as a daemon thread, so it is capable of keeping an application from terminating. If a caller wants to terminate a timer's task execution thread rapidly, the caller should invoke the timer's cancel method."

My question is: What is the difference between a daemon Timer and non-daemon Timer? Which (if either) is lighter weight? Is it simply that an executing daemon Timer will not prevent an application from terminating

PS. I'm new to this forum-posting lark. Have I posted an appropriate amount of information? Is it too much to read? I could have just said "Explain daemon timers plz?"

Here is what I found in Thread API docs.

Quote:

---

The Java Virtual Machine continues to execute threads until either of the following occurs:

The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

---

Which means if you run something as a daemon thread then JVM will not wait for terminating even if its running.

For your case you may want to stop execution if all threads are done. so it should be fine to run it as daemon.

____________________________________________
Priya,
Cooking is Fun | Eat Healthy Stay Fit | Sweets | Raita | Bread | Dal| Snacks

Looks appropriate to me.

JVM cannot exit as long as any non dameon threads are running. If a Thread has completed it's run() method, it is finished. In that condition the issue is probably not going to prevent JVM from completing.

For lightweight I suggest lowering the priority just a notch, not way low.

For what you state as what this is supposed to do I would set daemon, lower priority one notch, and examing how long the task takes to complete one cycle of run method.

Be advised, no matter how much work is done the OS has override on what gets scheduled and will do things as machinery does things, not how a human thinks it should go.

I did some good testing early on, that last is really a suprise when it happens.

Setting threads to daemon is a good idea generally, so that the application really does end when the last windows closes. However, that won't affect performance.

NJ is correct in saying that lowering a thread's priority slightly can improve performance of other threads, but there are a couple of catches.

The "Java" priority is different from the OS priority, which is what matters. Lowering the Java priority a notch may not affect the OS priority, if the Java priority has more notches than the OS priority.

For example, the Java priority can be 1 to 10. However, in .NET at least, Windows offers only five priorities. If Java priority 5 gets interpreted as Windows priority Normal, then Java priority 6 will likely also be interpreted as Windows priority Normal.

Also, for a sensitive operation like performance monitoring, it might make sense to *increase* the thread priority, since you want readings at very regular intervals.

The key is to get and save your measurements with as little overhead as possible. Unless you are doing something very cumbersome, this thread should not affect performance.

Another option is to have your algorithm code simply note the time, using System.nanoTime, every so many cycles.

Quote:

---

Originally Posted by Steve11235

NJ is correct in saying that lowering a thread's priority slightly can improve performance of other threads, but there are a couple of catches.

---

Several.

Quote:

---

Originally Posted by Steve11235

Also, for a sensitive operation like performance monitoring, it might make sense to *increase* the thread priority, since you want readings at very regular intervals.

---

Actually performance monitor is really a kernel op, cannot be tight from userland.

Quote:

---

Originally Posted by Steve11235

The key is to get and save your measurements with as little overhead as possible. Unless you are doing something very cumbersome, this thread should not affect performance.

---

jni to a single op,....time under java tends to use milliseconds, implementing perf monitor from Java code is a study project at best.

Quote:

---

Originally Posted by Steve11235

Another option is to have your algorithm code simply note the time, using System.nanoTime, every so many cycles.

---

I did some testing early, my first program stacked up as many Threads as the underlying OS would support file handles, it ran in a manner that clearly shows the scheduling of what happens has greater basis in how the OS is implemented rather than any fancy code I could write.

Thankyou for your insightful discussion! I will go ahead and set as daemon.

Great discussion...Goseph would you like to mark this thread as solved if it has answered your question.

____________________________________________
Priya,
Cooking is Fun| Eat Healthy Stay Fit | Sweets | Raita | Bread | Dal| Snacks

[QUOTE=priyanka.dandekar;56795]Great discussion...Goseph would you like to mark this thread as solved if it has answered your question.

ok!