On Thu, 3 Apr 2008, Mulyadi Santosa wrote:
> On Wed, Apr 2, 2008 at 9:52 PM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
... snip ...
> > * only the thread group leader of a multithreaded application is
> > on the system-wide task list. the additional threads in that
> > thread group are on a separate list managed by the thread group
> > leader.
> uhm, i don't think so. AFAIK in new CFS scheduler, they are just
> treated "differently" to avoid excessive scheduling latency between
> them.. something you probably need because in user space programming
> we usually expect fast switching between threads.
just to summarize, if you examine these fields from struct
"task_struct" (only the fields i care about are listed here):
struct task_struct {
struct list_head tasks;
pid_t pid;
pid_t tgid;
struct task_struct *group_leader; /* threadgroup leader */
struct list_head thread_group;
};
this is what i gather:
* "tasks" is the system-wide lists of tasks, including all threads in
a thread group (unlike what i posted earlier)
* "pid" is the *individual* process ID of each process/thread
* "tgid" is the ID of the thread group leader (and it's what's
returned by getpid(), which is required by POSIX)
* "group_leader" is the pointer to the thread group leader which,
AFAICT, should have a process ID of "tgid"
* "thread_group" represents the doubly-linked list of threads in this
thread group (an empty list in the non-thread case, i'm guessing)
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
