|
Home > Archive > Unix Programming > July 2004 > contentionscope in pthreads
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
contentionscope in pthreads
|
|
|
| I want to know about the attribute contentionscope in pthread. A
multithreaded program in execution is a single process ( as far as
kernel is concerned ). It is upto the program to divide the CPU time
slice among threads.
If contentionscope is PTHREAD_SCOPE_PROCESS, then CPU time slice of one
process is divided among each threads.
If contentionscope is PTHREAD_SCOPE_SYSTEM, each thread gets its own
CPU time slice from the kernel. Is this correct?
Assume a CPU schedular schedules 10 processes ( 9 processes + 1
multithreaded process with 10threads ). Assume schedular gives equal
time slice for each processes. then it should give 1/10th of CPU time
to each process(for PTHREAD_SCOPE_PROCESS) and 1/19th of CPU time to
each process( for PTHREAD_SCOPE_SYSTEM ). Is this correct? pls clarify
me
| |
| Casper H.S. Dik 2004-07-16, 5:53 pm |
| "ravi" <ec_au_ravi2000@yahoo.com> writes:
>I want to know about the attribute contentionscope in pthread. A
>multithreaded program in execution is a single process ( as far as
>kernel is concerned ). It is upto the program to divide the CPU time
>slice among threads.
Kinda.
>If contentionscope is PTHREAD_SCOPE_PROCESS, then CPU time slice of one
>process is divided among each threads.
>If contentionscope is PTHREAD_SCOPE_SYSTEM, each thread gets its own
>CPU time slice from the kernel. Is this correct?
It's a lot fuzzier than that; a system is free to make as many
"system scope" threads for "process scope" threads as it wants so
the effect might be somewhere between 1 and 10 time sliced threads.
(E.g., the Solaris 8 and earlier thread library would give you a number
of threads depending on whether you blocked in system calls; in
Soaris 9 and later you always get the same type of thread and they
are all "system threads".
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| David Butenhof 2004-07-28, 6:19 pm |
| ravi wrote:
> I want to know about the attribute contentionscope in pthread. A
> multithreaded program in execution is a single process ( as far as
> kernel is concerned ). It is upto the program to divide the CPU time
> slice among threads.
>
> If contentionscope is PTHREAD_SCOPE_PROCESS, then CPU time slice of one
> process is divided among each threads.
> If contentionscope is PTHREAD_SCOPE_SYSTEM, each thread gets its own
> CPU time slice from the kernel. Is this correct?
>
> Assume a CPU schedular schedules 10 processes ( 9 processes + 1
> multithreaded process with 10threads ). Assume schedular gives equal
> time slice for each processes. then it should give 1/10th of CPU time
> to each process(for PTHREAD_SCOPE_PROCESS) and 1/19th of CPU time to
> each process( for PTHREAD_SCOPE_SYSTEM ). Is this correct? pls clarify
> me
The standard doesn't say anything at all about how CPU time is divided
between threads within a process. (The timeslicing definition is more
general than that -- it refers to system context switching behavior.)
The difference between PTHREAD_SCOPE_PROCESS (PCS) and PTHREAD_SCOPE_SYSTEM
(SCS) is about thread priority and policy visibility. An SCS thread's
policy and priority are visible to (and followed by) the global (system)
scheduler. That is, if you have an SCS thread scheduled at SCHED_FIFO and
priority 63 (presuming that's the maximum system priority), and a thread
within the kernel (e.g., for a driver) that operates at priority 62, or a
PROCESS running at priority 62, then on a uniprocessor your SCS thread will
run instead of (or even PREEMPT) that process, and/or that internal kernel
thread.
A PCS priority thread at SCHED_FIFO/63, however, is only REQUIRED (or
guaranteed, depending on your point of view) to be scheduled against other
threads within the same process. Effectively, the thread may seem (to the
kernel) to be running at the default PROCESS priority, which is probably a
lot lower. It probably won't preempt the internal kernel thread, or any
thread in another process. On the other hand, there's no guarantee that it
WON'T.
--
/--------------------[ David.Butenhof@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
|
|
|
|
|