thread id - Unix

This is a discussion on thread id - Unix ; Roman Mashak wrote: > Hello, > > I'm studying POSIX threads and wrote such a small sample. I ran this in > cygwin and linux (debian, kernel 2.6.18): > > #include > > #include > #include > > void *thread_func(void ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: thread id

  1. Re: thread id

    Roman Mashak wrote:
    > Hello,
    >
    > I'm studying POSIX threads and wrote such a small sample. I ran this in
    > cygwin and linux (debian, kernel 2.6.18):
    >
    > #include
    >
    > #include
    > #include
    >
    > void *thread_func(void *arg)
    > {
    > printf("thread %lu ", pthread_self());
    > pthread_exit(NULL);
    > }
    >
    > int main(void)
    > {
    > pthread_t tid;
    >
    > while (1) {
    > if (pthread_create(&tid, NULL, thread_func, NULL) != 0) {
    > perror("pthread_create()");
    > return -1;
    > }
    >
    > if (pthread_join(tid, NULL) != 0) {
    > perror("pthread_join()");
    > return -1;
    > }
    > printf("and terminated, sleep 3 sec.\n");
    > sleep(3);
    > }
    >
    > return 0;
    > }
    >
    > On both systems I always get the same thread id, whenever I execute the
    > program. Is this normal behavior, I wonder why?
    > Thanks in advance.
    >
    > With best regards, Roman Mashak. E-mail: mrv@tusur.ru
    >
    >



    You aren't printing the thread ID. You can't anyway. pthread_t is an opaque
    type and isn't necessarily an integer so your conversion to long unsigned is bogus.

    In your case it is most likely a pointer type. What is happening is you are
    printing the address of where the real data is located. That is why it comes up
    the same. Same program, same offset.

    Try running it on different Unix's and you will get different results.

    Also thread ID's are specific to a process. So it is possible to have two
    identical thread ID's on a system if the threads belong to different processes.
    The kernel knows the difference.


  2. thread id

    Hello,

    I'm studying POSIX threads and wrote such a small sample. I ran this in
    cygwin and linux (debian, kernel 2.6.18):

    #include

    #include
    #include

    void *thread_func(void *arg)
    {
    printf("thread %lu ", pthread_self());
    pthread_exit(NULL);
    }

    int main(void)
    {
    pthread_t tid;

    while (1) {
    if (pthread_create(&tid, NULL, thread_func, NULL) != 0) {
    perror("pthread_create()");
    return -1;
    }

    if (pthread_join(tid, NULL) != 0) {
    perror("pthread_join()");
    return -1;
    }
    printf("and terminated, sleep 3 sec.\n");
    sleep(3);
    }

    return 0;
    }

    On both systems I always get the same thread id, whenever I execute the
    program. Is this normal behavior, I wonder why?
    Thanks in advance.

    With best regards, Roman Mashak. E-mail: mrv@tusur.ru



  3. Re: thread id

    i think pthread_t is a pointer under cygwin, and integral number
    under linux.

    mojmir


  4. Re: thread id

    "Golden California Girls" wrote in message
    news:QoydnYcdwfDOUIXanZ2dnUVZ_qKgnZ2d@championbroa dband.com...

    > You aren't printing the thread ID. You can't anyway. pthread_t is an
    > opaque
    > type and isn't necessarily an integer so your conversion to long unsigned
    > is bogus.
    >
    > In your case it is most likely a pointer type. What is happening is you
    > are


    There's no pointer, what did you mean?

    > printing the address of where the real data is located. That is why it
    > comes up
    > the same. Same program, same offset.
    >
    > Try running it on different Unix's and you will get different results.
    >
    > Also thread ID's are specific to a process. So it is possible to have two
    > identical thread ID's on a system if the threads belong to different
    > processes.
    > The kernel knows the difference.
    >

    This code compiled on FreeBSD 6.2 produces output with variadic thread IDs.

    --
    Best regards, Roman



  5. Re: thread id

    On Oct 19, 6:19 pm, "Roman Mashak" wrote:

    > printf("thread %lu ", pthread_self());


    This does *NOT* print the thread ID. It gets the thread ID and tells
    printf to print a long unsigned integer.

    > On both systems I always get the same thread id, whenever I execute the
    > program. Is this normal behavior, I wonder why?
    > Thanks in advance.


    You don't "get the same thread id". You get the same result when you
    pass 'printf' a thread ID and tell it to print a long unsigned
    integer. There is no reason to thing these two things are the same.

    > That's the point, the definition of the type is quite sane in cygwin:
    > typedef __uint32_t pthread_t;


    That definition is not for you, it's for the implementation.

    DS


  6. Re: thread id

    Roman Mashak wrote:
    > "mojmir" wrote in message
    > news:1193061794.650140.157020@z24g2000prh.googlegr oups.com...
    >> i think pthread_t is a pointer under cygwin, and integral number
    >> under linux.

    > That's the point, the definition of the type is quite sane in cygwin:
    >
    > typedef __uint32_t pthread_t;
    >


    Yes, 32 bits of you don't know what. SUS says it (a thread ID) can be a
    structure. Dragging the book out[1] Solaris uses an integer. Linux does as
    well, but it also creates a new process for each thread. Free BSD and Mac O/S
    both use a pointer to a structure.


    [1] Advanced Programming in the UNIX Environment second edition, section 11.4


    If the OP was wondering why he was getting the same for each run, thread ID's
    only mean something in the process. New process and they could start at 1 again.

  7. Re: thread id

    On Oct 23, 6:16 pm, "Roman Mashak" wrote:
    > "mojmir" wrote in message
    >
    > news:1193061794.650140.157020@z24g2000prh.googlegr oups.com...>i think pthread_t is a pointer under cygwin, and integral number
    > > under linux.

    >
    > That's the point, the definition of the type is quite sane in cygwin:
    >
    > typedef __uint32_t pthread_t;
    >
    > --
    > Best regards, Roman


    there is another one in /usr/include/cygwin/types.h

    mojmir


  8. Re: thread id

    "mojmir" wrote in message
    news:1193061794.650140.157020@z24g2000prh.googlegr oups.com...
    >i think pthread_t is a pointer under cygwin, and integral number
    > under linux.

    That's the point, the definition of the type is quite sane in cygwin:

    typedef __uint32_t pthread_t;

    --
    Best regards, Roman



  9. Re: thread id

    Hello, David!
    You wrote on Mon, 22 Oct 2007 17:41:43 -0700:

    ??>> printf("thread %lu ", pthread_self());

    DS> This does *NOT* print the thread ID. It gets the thread ID and tells
    DS> printf to print a long unsigned integer.
    So, what is the practical way to print out the ID of thread?

    ??>> On both systems I always get the same thread id, whenever I execute
    ??>> the program. Is this normal behavior, I wonder why? Thanks in advance.

    With best regards, Roman Mashak. E-mail: mrv@tusur.ru



  10. thread id

    RM> So, what is the practical way to print out the ID of thread?

    You were told that is an opaque type right at the start of this thread.


  11. Re: thread id

    On Oct 23, 4:14 pm, "Roman Mashak" wrote:

    > DS> This does *NOT* print the thread ID. It gets the thread ID and tells
    > DS> printf to print a long unsigned integer.


    > So, what is the practical way to print out the ID of thread?


    Well, first you have to assign each thread a printable ID. POSIX gives
    you all the tools to do this with functions like pthread_key_create.

    DS


  12. Re: thread id

    Hello, David!
    You wrote on Wed, 24 Oct 2007 17:28:05 -0700:

    ??>> So, what is the practical way to print out the ID of thread?

    DS> Well, first you have to assign each thread a printable ID. POSIX gives
    DS> you all the tools to do this with functions like pthread_key_create.
    Thank you so much, this is what I was looking for.

    With best regards, Roman Mashak. E-mail: mrv@tusur.ru



  13. Re: thread id

    On Oct 22, 9:25 pm, Golden California Girls
    wrote:

    > Yes, 32 bits of you don't know what. SUS says it (a thread ID) can be a
    > structure. Dragging the book out[1] Solaris uses an integer. Linux does as
    > well, but it also creates a new process for each thread. Free BSD and Mac O/S
    > both use a pointer to a structure.


    Linux does not create a new process for each thread. This is a
    frequently-repeated myth. By definition, a process consists of all the
    threads that share a view of memory, so this is not only not what
    Linux does, it's impossible.

    DS


  14. Re: thread id

    David Schwartz wrote:

    > Golden California Girls wrote:
    >
    >> Yes, 32 bits of you don't know what. SUS says it (a thread ID) can be a
    >> structure. Dragging the book out[1] Solaris uses an integer. Linux does as
    >> well, but it also creates a new process for each thread. Free BSD and Mac O/S
    >> both use a pointer to a structure.

    >
    > Linux does not create a new process for each thread. This is a
    > frequently-repeated myth. By definition, a process consists of all the
    > threads that share a view of memory, so this is not only not what
    > Linux does, it's impossible.


    I suppose it's a matter of definition.

    What Josh Aas wrote might clear some confusion (or not).

    3.6 Linux Processes / Threads

    Linux takes a unique approach to implementing the process and thread
    abstractions. In Linux, all threads are simply processes that might
    share certain resources. Instead of being something different than a
    thread or a group of threads, a process in Linux is simply a group of
    threads that share something called a thread group ID (TGID) and
    whatever resources are necessary. In order to reconcile Linux's
    treatment of processes and threads with the terms themselves, the term
    "task" will be used from here on to mean a Linux thread - it does not
    mean thread in the POSIX sense. "Process" or "thread" will be used only
    when the difference really matters. In the Linux task structure
    task_struct (one of which exists for each thread), the TGID that is a
    process's POSIX PID is stored as [task_struct]->tgid. Linux assigns
    unique "PID"s to every thread ([task_struct]->pid), but the (POSIX) PID
    that most people think of is really a task's TGID. It is worth
    mentioning that this model, combined with certain tricks like a COW
    (Copy On Write) forking algorithm causes process and thread spawning to
    be very fast and efficient in Linux, whereas spawning a process is much
    more expensive than spawning threads on many other operating systems
    (e.g. BSD UNIX and Microsoft Windows).

    Unfortunately, further details about Linux's process and thread
    implementation would be out of the scope of this paper. It is only
    important to know that Linux considers processes to be merely groups of
    threads and does not differentiate between the two. Because of this,
    Linux schedules threads only, essentially ignoring what POSIX processes
    they belong to.

    Understanding the Linux 2.6.8.1 CPU Scheduler
    http://josh.trancesoftware.com/linux..._scheduler.pdf

    Regards.

  15. Re: thread id


    Spoon wrote:

    > I suppose it's a matter of definition.


    The confusion is due to historical reasons. Sadly, Linux has called
    what were really KSEs (kernel scheduling entities) "processes" because
    the difference was not important. Later, when it became important, the
    term "process" was ingrained in structure names, variable names,
    documentation, and people's brains.

    > Instead of being something different than a
    > thread or a group of threads, a process in Linux is simply a group of
    > threads that share something called a thread group ID (TGID) and
    > whatever resources are necessary.


    In other words, a process consists of one or more threads. So if you
    have 10 threads, you have 10 processes *or* *less*.

    They invented a new term "TGID" even though the common term "process
    ID" or "PID" means precisely this. They did this because they already
    used the term "PID" to refer to what is commonly known as a
    "TID" (thread ID).

    It's kind of like how engineers use 'j' for complex numbers instead of
    'i' because they used 'i' for current. They used 'i' for current
    because 'c' was already taken for charge. So you wind up with lots of
    terms that don't make any sense if you start out without knowing where
    you are going to end up.

    > Unfortunately, further details about Linux's process and thread
    > implementation would be out of the scope of this paper. It is only
    > important to know that Linux considers processes to be merely groups of
    > threads and does not differentiate between the two. Because of this,
    > Linux schedules threads only, essentially ignoring what POSIX processes
    > they belong to.


    If Linux considers processes to be groups of threads, then it must
    distinguish between processes and threads. After all, threads are not
    considered groups of processes.

    The Linux scheduler does not discriminate between threads that are
    part of a multi-threaded process and threads that are the sole thread
    of a process. But it definitely does discriminate between threads that
    are part of the same process and threads that aren't. To fail to do so
    would cause a large performance hit.

    DS


  16. Re: thread id

    Spoon writes:
    > David Schwartz wrote:
    >> Golden California Girls wrote:
    >>
    >>> Yes, 32 bits of you don't know what. SUS says it (a thread ID) can be a
    >>> structure. Dragging the book out[1] Solaris uses an integer. Linux does as
    >>> well, but it also creates a new process for each thread. Free BSD and Mac O/S
    >>> both use a pointer to a structure.

    >> Linux does not create a new process for each thread. This is a
    >> frequently-repeated myth. By definition, a process consists of all the
    >> threads that share a view of memory, so this is not only not what
    >> Linux does, it's impossible.

    >
    > I suppose it's a matter of definition.


    Using terms always is. And the UNIX(*) definition for a process is

    3.289 Process

    An address space with one or more threads executing within that
    address space, and the required system resources for those
    threads.

    and for a thread

    3.393 Thread

    A single flow of control within a process. Each thread has its
    own thread ID, scheduling priority and policy, errno value,
    thread-specific key/value bindings, and the required system
    resources to support a flow of control. Anything whose address
    may be determined by a thread, including but not limited to
    static variables, storage obtained via malloc(), directly
    addressable storage obtained through implementation-defined
    functions, and automatic variables, are accessible to all
    threads in the same process.

    > What Josh Aas wrote might clear some confusion (or not).
    >
    > 3.6 Linux Processes / Threads
    >
    > Linux takes a unique approach to implementing the process and thread
    > abstractions. In Linux, all threads are simply processes that might
    > share certain resources.


    Since processes are defined as being associated with an address space
    of their own, writing about 'processes which may share an address
    space' is just nonsense. What the author meant to say (and actually
    says in a somewhat confused way) is that the Linux kernel threading
    support evolved from the preexisting support for single-threaded
    processes.

    > Instead of being something different than a thread or a group of
    > threads, a process in Linux is simply a group of threads that share
    > something called a thread group ID (TGID) and whatever resources are
    > necessary.


    The statements 'a thread is a process' and 'a process is a group of
    threads' cannot possibly both be true.

    [...]

    > Because of this, Linux schedules threads only, essentially ignoring
    > what POSIX processes they belong to.


    This is called 1:1 threading model and I would wager a bet that this
    term is older than the Linux-kernel multi-threading support itself.

  17. Re: thread id

    Rainer Weikusat writes:
    >Spoon writes:
    >> David Schwartz wrote:
    >>> Golden California Girls wrote:
    >>>
    >>>> Yes, 32 bits of you don't know what. SUS says it (a thread ID) can be a
    >>>> structure. Dragging the book out[1] Solaris uses an integer. Linux does as
    >>>> well, but it also creates a new process for each thread. Free BSD and Mac O/S
    >>>> both use a pointer to a structure.
    >>> Linux does not create a new process for each thread. This is a
    >>> frequently-repeated myth. By definition, a process consists of all the
    >>> threads that share a view of memory, so this is not only not what
    >>> Linux does, it's impossible.

    >>
    >> I suppose it's a matter of definition.

    >
    >Using terms always is. And the UNIX(*) definition for a process is
    >
    > 3.289 Process
    >
    > An address space with one or more threads executing within that
    > address space, and the required system resources for those
    > threads.
    >
    >and for a thread
    >
    > 3.393 Thread
    >
    > A single flow of control within a process. Each thread has its
    > own thread ID, scheduling priority and policy, errno value,
    > thread-specific key/value bindings, and the required system
    > resources to support a flow of control. Anything whose address
    > may be determined by a thread, including but not limited to
    > static variables, storage obtained via malloc(), directly
    > addressable storage obtained through implementation-defined
    > functions, and automatic variables, are accessible to all
    > threads in the same process.
    >
    >> What Josh Aas wrote might clear some confusion (or not).
    >>
    >> 3.6 Linux Processes / Threads
    >>
    >> Linux takes a unique approach to implementing the process and thread
    >> abstractions. In Linux, all threads are simply processes that might
    >> share certain resources.

    >
    >Since processes are defined as being associated with an address space
    >of their own, writing about 'processes which may share an address
    >space' is just nonsense. What the author meant to say (and actually
    >says in a somewhat confused way) is that the Linux kernel threading
    >support evolved from the preexisting support for single-threaded
    >processes.
    >
    >> Instead of being something different than a thread or a group of
    >> threads, a process in Linux is simply a group of threads that share
    >> something called a thread group ID (TGID) and whatever resources are
    >> necessary.

    >
    >The statements 'a thread is a process' and 'a process is a group of
    >threads' cannot possibly both be true.
    >
    >[...]
    >
    >> Because of this, Linux schedules threads only, essentially ignoring
    >> what POSIX processes they belong to.

    >
    >This is called 1:1 threading model and I would wager a bet that this
    >term is older than the Linux-kernel multi-threading support itself.


    1:1 and M:N threading models predate any _linux_.

    soctt

+ Reply to Thread