• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1375
  • Last Modified:

set priority for java.util.Timer

Hi,

 How do i set priority for the underlying thread associated to a Timer/TimerTask
0
zuzzi2
Asked:
zuzzi2
  • 5
  • 3
  • 3
  • +2
2 Solutions
 
objectsCommented:
don't think you can
0
 
tomboshellCommented:
I don't think that goes with the concept of a timer.  A timer is based upon time and not priorities.  I would guess, but have never done this, that you could build a utils TimerTask with an instance of a Thread object (that you modify) since it implements the Runnable interface.  But I could not guarantee that it would work the way that you expect.

The best would be to simply make a high priority thread that contains a timer within it.  The thread container would then have a high priority, but then you will actually have two threads.  Or simply have your new thread calcuate the time delays itself (the old way that everyone did before Timers came with the JDK)
0
 
Mayank SAssociate Director - Product EngineeringCommented:
You can always try to write your own timer class and set the priority there :)
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
objectsCommented:
tomboshell's comment got me thinking, you should be able to access thread from any task using Thread.currentThread()
0
 
Mayank SAssociate Director - Product EngineeringCommented:
I guess that timers use a back-ground thread of their own which sleeps for the specified duration (timer-interval) and then raises an event. That way, I don't think that Thread.currentThread () would give you access to 'that' Thread because it would be encapsulated within the Timer class. I could be wrong, though (this is only a guess).
0
 
Mayank SAssociate Director - Product EngineeringCommented:
However, in such cases - setting priority to a timer's thread does not make sense because all you want it to do is sleep.
0
 
tomboshellCommented:
Yep, that will access the thread.  The only problem I ever had with that is when I tried to access that call within a class that is not the "owner" of the thread, ie it needs to be used from the calling class.  But, that said, I *may* have done something wrong in the past (that hurt).  On-the-fly (runtime changes) to the started thread can be tricky.  
0
 
objectsCommented:
> That way, I don't think that Thread.currentThread () would give you access to 'that'
> Thread because it would be encapsulated within the Timer class

Yes, but it runs the task on that thread :)


0
 
CEHJCommented:
It can't be done AFAIK. It's fully encapsulated, and even if you could break the encapsulation, you wouldn't be able to restart it with a new priority
0
 
objectsCommented:
> It can't be done AFAIK.

As I originally stated.
0
 
Jim CakalicSenior Developer/ArchitectCommented:
One of the things that makes java.util.Timer scalable is that it only has a single thread on which all TimerTasks execute, sequentially, according to the javadoc. It goes on to say, "Timer tasks should complete quickly. If a timer task takes excessive time to complete, it "hogs" the timer's task execution thread. This can, in turn, delay the execution of subsequent tasks, which may "bunch up" and execute in rapid succession when (and if) the offending task finally completes."

So it is doubtful that the designers wanted you to have a convenient mechanism to change thread priority -- particularly lower -- because then it would have the undesirable consequences mentioned above. And changing the thread priority to something higher would likely result in potential starvation of other threads when TimerTasks were executing.

However, if you really want to have a Timer and/or TimerTask that permits manipulation of thread priority you could easily scrounge the code out of the src.zip in your JDK implementation, change its packaging, and then make whatever changes you desired.

Best regards,
Jim Cakalic
0
 
CEHJCommented:
>>As I originally stated.

'Originally' being the operative word. You seemed to be stating something rather different later in the thread
0
 
objectsCommented:
I offered a workaround to try, that doesn't at all change what I originally stated.
0
 
CEHJCommented:
>>Any reason to post your last comment?

I shall discuss that with you out of this thread if you wish
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 5
  • 3
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now