• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Problems with thread priority

 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In this code I expected the output would be
CRM Batch 1
MDM Batch 1
PEGA Batch 1
and so on...but the output is coming in random order.why is that?why does the setpriority does not have any effect?
 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're best off not fiddling with (or relying on) the priorities of threads. It's just something that in practice doesn't work like the theory suggests it should.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In addition to the fact that the schedule is free to use the priority as it sees fit (or ignore it altogether), your threads do things that make priority much less relevant:

1) sleep()

2) I/O

3) Very little CPU time needed

Even if a particular scheduler rigorously respects priority, I would only expect that to matter for threads that are a) ready for CPU time at the same time and b) competing for the same CPU or core. If a thread is sleeping or waiting on I/O, there's no reason for the scheduler not to give time to another thread, even one of lower priority. That would just be wasteful. And since neither sleep nor I/O are predictable as to when they'll be done, there's no reason to assume that all your threads will be ready for CPU at the same time. In addition to that, there's probably some minimum time slice that the scheduler will give a thread before bumping it out in favor of a higher priority one, and your threads need so little CPU time at one shot before they sleep or do I/O that it's not likely the scheduler even gets a chance to bump one out.

If you do a more CPU-intensive task, longer running without so may interruptions in your code, you might see some effect of threads' priorities.
reply
    Bookmark Topic Watch Topic
  • New Topic