Subj : Re: Thread priority and policy
To   : comp.programming.threads
From : hemarangarajan
Date : Mon Mar 21 2005 09:14 pm

Hai,

thanks for the reply,

 i m porting it from Solaris 5.2 version
so i was able to create the POSIX equvivalent of bounded and detached
thread.

in my application
thread A recvs Multicast pkt
thread B writes it into a journl file (mainly for bk up
in thread c the rcvd pkt processed  and it is published  on a tcp

i want to make thread A to have the highest priority than thread B and
C




David Butenhof wrote:
> 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

.