Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Inexpensive Mechanism to Identify Threads Uniquely From User Level

IP.com Disclosure Number: IPCOM000113378D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 2 page(s) / 77K

Publishing Venue

IBM

Related People

Arendt, JW: AUTHOR [+4]

Abstract

In the classical case, there was one thread in a task. Library requests were satisfied either in the task address space or control was passed to the kernel where the request was processed and the result returned to the task. Since there was only one thread, there was no question as to which thread received the response.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Inexpensive Mechanism to Identify Threads Uniquely From User Level

      In the classical case, there was one thread in a task.  Library
requests were satisfied either in the task address space or control
was passed to the kernel where the request was processed and the
result returned to the task.  Since there was only one thread, there
was no question as to which thread received the response.

      Multiple threads running in a task generate a problem whereby
libraries need to keep track of the individual threads.  This is
easily seen in the case where library services are performed in
different tasks.  Here the library needs to associate a service to a
specific thread.  For example, if two threads make two separate
memory allocation requests, each thread needs to get the result of
its own request (e.g., one thread might get an error status back and
the other might get the virtual memory address of its new memory).  A
thread making a request must identify itself and send along a return
token.  The token can take on many forms, e.g., a request packet.  In
Mach the token is called a reply port.  These tokens are expensive to
create on demand, so they are usually cached by user thread.  Hence,
threads need to be able to identify themselves to fetch their cached
token.

      The problem of a general method for identifying threads has
turned out to be very difficult and frequently has some hardware
dependencies.  Most solutions are not efficient or do not scale well.
One brute force method is to make a kernel request that returns the
thread id of the calling thread.  This is not efficient as it
requires a switch to the kernel context and return.  An alternative
method places the thread id or token cache at the base of each
thread's stack.  But this fails when users recreate or move their
stacks.  Another method would be to have the operating system update
a known location in the users virtual memory with the thread id each
time a scheduling context decision is made.  This method fails when
threads in the same address space e...