Hi On Wed, Apr 2, 2008 at 9:52 PM, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > just to make *absolutely* sure that i'm using the terminology > correctly, here's how i understand processes and threads: > > * threads are, of course, just another type of process -- these are > commonly referred to simply as "tasks" yup, with additional note: threads likely share something e.g memory space, open files and so on... > * all processes have a process ID (PID), but related threads (those in > the same multithreaded application) have the *same* PID as returned by > getpid(). this is the PID of the "thread group leader" -- the initial > thread in that application. yeah correct > * while each thread has its own unique PID represented by the variable > "pid", the routine getpid() returns instead the thread group leader > represented by the variable "tgid", the thread group leader. (for > thread groups that consist of a single member, those two variables pid > and tgid will, naturally, contain the same value.) yeah.... > * 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. > how am i doing so far? you get A+ :)) regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
