Subj : Re: Thread priority and policy To : comp.programming.threads From : David Butenhof Date : Fri Mar 18 2005 01:39 pm Hema wrote: > > i am basically porting a application fro solaris to thread, > there are 3 threads (POSIX) > thread A is bounded thread > thread b and c are detached thread ,rest all are default parameters.( > i guess the scheduling policy will be SCHED_OTHER with the default > priority of 0) First, you say one thread is "bound[ed]", and the others "detached". While both of these terms make some sense in UI threads, the combination leads me to suspect that you might be confused. A "BOUND" thread in the Solaris UI thread model is equivalent to what POSIX calls "System Contention Scope" (SCS) -- the application-visible POSIX thread "personality" is permanently and exclusively bound to what POSIX loosely designates a "kernel scheduling entity" (or Solaris calls an LWP). If you're using Solaris 9 or later, you're always using bound/SCS threads, because there is no other kind. If you're using Solaris 8 or earlier, then you might indeed have a THR_BOUND UI thread, which corresponds to SCS, while the others are "not bound" or in POSIX terminology "Process Contention Scope" (PCS). Either PCS or SCS/BOUND threads may be created "joinable" (the default) or "detached"... in both the UI and POSIX thread models. Joinable threads will live on in some form until "reaped" by calling thr_join() or pthread_join(); while detached threads will dissolve completely as soon as they've terminated. (Meaning that the termination status cannot be retrieved.) > while processing i make the thread A as a RealTime thread by changing > it class to SCHED_RR(shuld i go for SCHED_FIFO or SCHED_RR??) I don't know -- what are the realtime REQUIREMENTS of your application? Presumably there are some, since you're using realtime scheduling. Without knowing WHY and HOW you're depending on priority scheduling, we cannot answer that question for you. > and i need to reduce the thread priority for thread b by 1 less than > the default priority and for thread C one more than the defaulrt > priority. Why would you need to do that, and what do you expect to accomplish by it? As you deduced, the default scheduling policy is SCHED_OTHER; which on Solaris (as on most general purpose UNIX systems) is a loosely defined "timeshare" scheduling policy subject to priority adjustment at the whim of the scheduler to maintain system scheduling goals. While many implementations allow you to specify a priority value for timeshare threads, the standard doesn't assign any meaning to it. And, in practice, setting the priority of a timeshare thread is much like whispering compliments to yourself -- it may make you feel better, but isn't necessarily accomplishing anything measurable. Yeah, "nice" can coerce the scheduler to give more time, ON AVERAGE, over a period of time, to "more important" timeshare threads. But the difference has no relevance to realtime scheduling goals. If your intent is to whisper "you're a good thread" to C in hope that it gains some statistically significant advantage over thread B during a substantial period of time, that's fine. If you imagine however that doing this will prevent thread B from running whenever thread C is able to run, or that thread B can never interrupt thread C while running, then you're on the wrong track entirely. The whole point of SCHED_OTHER is to say that you're out of the realtime scheduling domain. > in solaris i can use thr_setprio to change the priority > but in LINUX,when i try to change the priority(and not the scheduling > class) using pthread_setschedparam.i cannot because they are > SCHED_OTHER and only priority 0 is allowed for these class of thread. > should i make these threads as A RT thread?? if so why? So you're porting from Solaris/UI threads to Linux/POSIX threads? Hmm. Like Solaris 9, Linux threads are all SCS/BOUND. And as you may have already guessed, I'm just going to turn your questions back at you. Why do you WANT to change the priority? What do you expect that will gain for your application? If you NEED priority scheduling with distinct priorities, due to some real externally imposed realtime communication requirements, then you'll need to stop using SCHED_OTHER which is explicitly and by design NOT realtime. If you don't have real external realtime communication requirements, then you probably shouldn't be complicating and slowing your application by using priority scheduling in the first place. > and what is the main difference between SCHED_FIFO and sched_RR They're identical in all respects except that SCHED_RR threads are subject to timeslicing. That is, at defined intervals the scheduler will suspend a long-running SCHED_RR thread in order to schedule the next waiting thread at the same priority. (Regardless of whether that other thread is SCHED_RR or SCHED_FIFO, incidentally.) A SCHED_FIFO thread, on the other hand, once scheduled will continue running until it either blocks or until a thread of higher priority (again, either SCHED_FIFO or SCHED_RR) becomes able to run -- at which point the higher priority thread will preempt the running thread. -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .