hyPACK-2013 Mode 1 : POSIX Thread Programming (Pthreads)

The software threading model on the computing platform which consists of multi-core processors play an important role to understand and enhance the performance of your application. Several factors such as proper use of threading, understanding of how threads operate, algorithm used for your application, the threading application programming interface (API), the compiler runtime environment, and the number of multi-cores used for your application. Example programs using different APIs. Compilation and execution of Pthread programs, programs numerical and non-numerical computations are discussed using different thread APIs to understand Performance issues on mutli-core processors.

Introduction       Why Pthreads?       An Overview of Pthreads       Pthreads Lib. Calls

Compilation & Execution     Errors in threaded Prog.     Thread FAQ

References : Multi-threading     OpenMP     Java Threads     Books     MPI   Benchmarks  

• Pthreads programs to illustrate basic Pthread API library calls :
  Examples include some introductory programs Creating Threads, Managing Threads. Thread communications, Thread synchronization, Atomic Operations, Critical section, thread semaphores (mutex), Stack management, Join Operations and Processor affinity. Simple programs using thread APIs are discussed.
  

• Programs based on Numerical Computations (Dense Matrix Comp.) using thread APIs. :
  Examples programs on numerical integration of "pi" value by using different algorithms vector-vector multiplication using block striped partitioning, matrix-vector multiplication using self scheduling algorithm, and block checkboard partitioning, computation of Infinity norm of the square matrix using block striped partitioning. The focus is to use different thread APIs and understand Performance issues on mutli-core processors.
  

• Non-Numerical Comp. (Sorting, Searching, Producer-Consumer) using thread APIs.:
  Example programs on Sorting, Searching algorithms, Producer Consumer programs & Thread-I/O programs are discussed. The focus is to use different thread APIs and understand Performance issues on mutli-core processors.

• Test suite of Programs/Kernels and Benchmarks on Multi-Core Processors :
  A test suite of pthread programs on selective Dense Matrix computations, and sorting/Searching Algorithms, Thread based I/O are discussed on mutli-core processors. Different thread APIs have been used to understand Performance issues on mutli-core processors.
  
  



• Pthreads programs to illustrate read write API library calls :
  Programs that illustrate the use of Read-Write Lock using different read-write lock APIs are described.Sample demo code that gives basic idea of how to use Read-Write Lock and one sample application using both mutex and Read-Write Lock is described so that one can get better idea of what is exact difference between these synchronization constructs and how to use them.
  
  



• Pthreads programs to illustrate producer/consumer program for large no. of threads :
  Programs that illustrate the application of Pthreads to producer / consumer problem with large number of producers and consumers. It illustrates the usage of Pthreads for large no. of threads reading and writing to vectors implemented in 'indexed-access' (or array implementation) and 'sequential-access' (or linked list implementation). It also shows how the problem can be solved using the Mutex objects and condition-variable objects of Pthreads. It also illustrates 'thread-affinity' setting, to bind threads to particular number of cores. For different thread-affinity masks, the performance can be observed.
  
  

• Pthreads programs to illustrate simple media player :
  Pthread program for simple media streaming player, which consists of a thread monitoring a network port for arriving data, a decompressor thread for decompressing packets and generating frames in a video sequence, and a rendering thread that displays frames at programmed intervals.
  
  These three threads must communicate via shared buffers - an in-buffer between the network and decompressor, and an out-buffer between the decompressor and renderer. Implement this simple threaded framework. The network thread calls a dummy function listen_to_port to gather data from the network. For the sake of this program, this function generates a random string of bytes of desired length. The decompressor thread calls function decompress, which takes in data from the in-buffer and returns a frame of predetermined size.
  
  For this exercise, generate a frame with random bytes. Finally the render thread picks frames from the out buffer and calls the display function. This function takes a frame as an argument, and for this exercise, it does nothing. Implement this threaded framework using condition variables. Note that you can easily change the three dummy functions to make a meaningful streaming media decompressor.
  
  

Introduction to PThreads

POSIX threads or Pthreads is a portable threading library, which provides consistent programming interface across multiple operating systems. Pthreads is emerged as a standard threading interface for Linux and Unix platforms. A number of vendors provide vendor specific thread APIs. More core Pthreads functions on thread creation and destruction, synchronization and other thread features. In shared memory multiprocessor architectures, such as SMPs, threads can be used to implement parallelism. Historically, hardware vendors have implemented their own proprietary versions of threads, making portability a concern for software developers.

A Thread is a 'Light Weight Process'. A thread is a stream of instructions that can be scheduled as an independent unit. A thread exists within a process, and uses the process resources. Since threads are very small compared with processes, thread creation is relatively cheap in terms of CPU costs. As processes require their own resource bundle, and threads share resources, threads are likewise memory frugal. There can be multiple threads within a process. Multithreaded programs may have several threads running through different code paths "simultaneously".

The IEEE specifies a standard 1003.1c-1995, POSIX API. For UNIX systems, a standardized C language threads programming interface has been specified by the IEEE POSIX 1003.1c standard. Implementations that adhere to this standard are referred to as POSIX threads, or Pthreads. The concepts used in this "Pthreads on Multi-Cores" are largely independent of the API and can be used for programming with other thread APIs (Windows NT threads, Solaris threads, Java threads etc.. ).

The Pthread module begins with an introduction to concepts, motivations, and design considerations for using Pthreads. Each of the three major classes of routines in the Pthreads API such as Thread Creation, Thread Termination, Thread Management, Mutex Variables, and Condition Variables. Example codes are used throughout to demonstrate how to use most of the Pthreads routines needed by a new Pthreads programmer.

An Overview of Pthreads

The most significant recent trend in mass-market processor sales has been the growth of multi-core processors. Concurrent programming solutions are required to take advantage of this parallel processing capability. Historically, hardware vendors have implemented their own proprietary versions of threads. These implementations differed substantially from each other making it difficult for programmers to develop portable threaded applications.

Several business motives drive the development of dual-core architectures. Additionally, for general-purpose processors, much of the motivation for multi-core processors comes from the increasing difficulty of improving processor performance by increasing the operating frequency (frequency-scaling). In order to continue delivering regular performance improvements for general-purpose processors, manufacturers such as Intel and AMD have turned to multi-core designs, sacrificing lower manufacturing costs for higher performance in some applications and systems. Multi-core architectures are being developed, but so are the alternatives. An especially strong contender for established markets is to integrate more peripheral functions into the chip.

Software benefits from multicore architectures where code can be executed in parallel. Under most common operating systems this requires code to execute in separate threads or processes. Each application running on a system runs in its own process so multiple applications will benefit from multicore architectures. Each application may also have multiple threads but, in most cases, it must be specifically written to utilize multiple threads. Operating system software also tends to run many threads as a part of its normal operation. Running virtual machines will benefit from adoption of multiple core architectures since each virtual machine runs independently of others and can be executed in parallel. Most application software is not written to use multiple concurrent threads intensively because of the challenge of doing so. A frequent pattern in multithreaded application design is where a single thread does the intensive work while other threads do much less.

In order to take full advantage of the capabilities provided by threads, a standardized programming interface was required. For UNIX systems, this interface has been specified by the IEEE POSIX 1003.1c standard (1995). Implementations,which adhere to this standard are referred to as POSIX threads, or Pthreads. Most hardware vendors now offer Pthreads in addition to their proprietary API's.

Pthreads are defined as a set of C language programming types and procedure calls, implemented with a pthread.h header/include file and a thread library - though the this library may be part of another library, such as libc.

The character P in Pthreads stands for POSIX.It is a set of threading interfaces developed by IEEE Committe in charge of specifying a portable operating system interface(POSIX). POSIX committee defined a basic set of functions and data structures that it hoped would have been used by numerous vendors so that threaded code can be ported easily across operating systems. It specifies API to handle most of actions required by threads.It is a library that has standardized functions for using threads across different platforms.

In general though, in order for a program to take advantage of Pthreads, it must be able to be organized into discrete, independent tasks which can execute concurrently. For example, if routine1 and routine2 can be interchanged, interleaved and/or overlapped in real time, they are candidates for threading as shown in Figure 1.

Figure 1. concurrent execution of pthreads

Programs having the following characteristics may be well suited for pthreads:

Work that can be executed, or data that can be operated on, by multiple tasks simultaneously

Block for potentially long I/O waits

Use many CPU cycles in some places but not others

Must respond to asynchronous events

Some work is more important than other work (priority interrupts)

Pthreads can also be used for serial applications, to emulate parallel execution. A perfect example is the typical web browser, which for most people, runs on a single cpu desktop/laptop machine.

Shared Memory Model

Symmetric multiprocessing (SMP) designs have been long implemented using discrete CPUs, the issues regarding implementing the architecture and supporting it in software are well known. In addition to operating system (OS) support, adjustments to existing software are required to maximize utilization of the computing resources provided by multi-core processors. Also, the ability of multi-core processors to increase application performance depends on the use of multiple threads within applications.

The most important challenge in shared-address-space programming is the decomposition of a single application into several, dependent and interacting tasks. The efficiency of the parallel program is highly dependent on this decomposition step: it determines the synchronization and communication overhead. Other challenges are synchronization and communication between parallel threads. Synchronizing parallel threads is a tedious task: synchronizing too often leads to inefficient program execution but not enough synchronization can lead to incorrect results due to the data races or condition hazards. Faulty synchronization can lead to deadlocks in the Shared-address-spcae programming.

The shared memory model is quite suitable to Pthread Programming and the users should understand concepts of synchronization, critical section and deadlock conditions. Synchronization is an enforcing mechanism used to impose constraints on the order of execution of threads. The features of the Shared memory model :

• All threads have access to the same global, shared memory
• Threads also have their own private data
• Programmers are responsible for synchronizing access (protecting) globally shared data.

Figure 2. Typical Shared Memory Model Using Threads

Thread Safeness

Thread-safeness: in a nutshell, refers an application's ability to execute multiple threads simultaneously without "clobbering" shared data or creating "race" conditions.

For example, suppose that your application creates several threads, each of which makes a call to the same library routine:

• This library routine accesses/modifies a global structure or location in memory.

• As each thread calls this routine it is possible that they may try to modify this global structure/memory location at the same time.

• If the routine does not employ some sort of synchronization constructs to prevent data corruption, then it is not thread-safe.

The developer should know about the thread-safety of the external library routines in order to obtain correct results.

Why Threads ?

Threaded programming models offer significant advantages over message-passing programming models along with some disadvantages. Several advantages of Pthread programming on Multi-core processors are listed below.

• Software Portability : Pthreaded applications can be developed on serial computing systems and run on Multi-Core as well as Parallel Processing Systems without any changes. This gives significant advantage of threaded APIs on software utilization and application development time.
  

• The primary motivation for using Pthreads is to realize potential program performance gains while reducing the overheads when multiple threads are used.
  

• Latency Hiding : The major overheads in serial /parallel programs are : access latency for memory access, I/O, and Communication. By enabling multiple threads to execute on the same processor, threaded APIs enable this latency to be hidden. The concept of masking associated overhead for threads can be achieved on Multi-Core platforms.
  
  

• When compared to the cost of creating and managing a process, a thread can be created with much less operating system overhead. Managing threads requires fewer system resources than managing processes.
  
  

• All threads within a process share the same address space. Inter-thread communication is more efficient and in many cases, easier to use than inter-process-communication.
  
  

• Threaded applications offer potential performance gains and practical advantages over non-threaded applications in several other ways.
  
  

• Overlapping CPU work with I/O: For example, a program may have sections where it is performing a long I/O operation. While one thread is waiting for an I/O system call to complete, other threads can perform CPU intensive work.
  
  

• Priority/real-time scheduling: Tasks that are more important can be scheduled to supersede or interrupt lower priority tasks.
  
  

• Synchronous event handling: tasks that service events of indeterminate frequency and duration can be interleaved. For example, a web server can both transfer data from previous requests and manage the arrival of new requests.
  
  

• Threades APIs allow the programmer to specify a large number of concurrent task and support system level dynamic mapping of tasks to the processors with a view to minimizing idling overheads. This provides an opportunity and threaded APIs aide the programmer to free from burden of explicit scheduling and load balancing.
  
  

• Multi-threaded applications will work on a uni-processor system; yet naturally take advantage of a multiprocessor system, without recompiling.
  
  

• In a multiprocessor environment, the most important reason for using Pthreads is to take advantage of potential parallelism. In order for a program to take advantage of Pthreads, it must be able to be organized into discrete,independent tasks that can execute concurrently.

Due to aforementioned advantages, the Pthreaded programs are significantly easier to write but achieving identical levels of performance for the two programs may require additional effort. With Widespread acceptance of the POSIX thread API, development tools for POSIX threads, transform to Multi-Core platforms is easy from the program development and software engineering aspects. The important issues such as Decomposition of data, Synchronization, Performance and Scalability require serious attention on Multi-cores.

The communication is implicit in shared-address-space programming and much of the effort associated with writing correct threaded programs is difficult. The correctness of the programs is spent on synchronizing concurrent threads and respect to their data accesses or scheduling. The synchronization primitives in Pthreads are mutual exclusion for shared variables, overheads of Locking, condition variables for Synchronization, controlling Thread and synchronization attributes, attribute objects for mutexes, thread cancellation, composite synchronization constructs and Barrier construct. The basic library calls used are listed below.

• int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void*(*start_routine) (void),(void *arg)) ;

Creates a new thread, initializes its attributes, and makes it runable.
The pthread_create subroutine creates a new thread and initializes its attributes using the thread attributes object specified by the attr parameter. The new thread inherits its creating thread's signal mask; but any pending signal of the creating thread will be cleared for the new thread.

The new thread is made runnable, and will start executing the start_routine routine, with the parameter specified by the arg parameter. The arg parameter is a void pointer; it can reference any kind of data. It is not recommended to cast this pointer into a scalar data type (int for example), because the casts may not be portable.

The pthread_create subroutine returns the new thread identifier via the thread argument. The caller can use this thread identifier to perform various operations on the thread. This identifier should be checked to ensure that the thread was successfully created.

The maximum number of threads that may be created by a process is implementation dependent.

Figure 4. Typical flow of number of Threads execution

Once created, threads are peers, and may create other threads. There is no implied hierarchy or dependency between threads.

• void pthread_exit(void *value_ptr)
  
  

Terminates the calling thread.

The pthread_exit subroutine terminates the calling thread safely, and stores a termination status for any thread that may join the calling thread. The termination status is always a void pointer; it can reference any kind of data. It is not recommended to cast this pointer into a scalar data type (int for example), because the casts may not be portable. This subroutine never returns.

Unlike the exit subroutine, the pthread_exit subroutine does not close files. Thus any file opened and used only by the calling thread must be closed before calling this subroutine.It is also important to note that the pthread_exit subroutine frees any thread- specific data, including the thread's stack. Any data allocated on the stack becomes invalid identifier, since the stack is freed and the corresponding memory may be reused by another thread. Therefore, thread synchronization objects (mutexes and condition variables) allocated on a thread'sstack must be destroyed before the thread calls the pthread_exit subroutine.

Returning from the initial routine of a thread implicitly calls the pthread_exit subroutine, using the return value as parameter.

• pthread_t pthread_self()
  
  

Returns the calling thread's identifier.

The pthread_self subroutine returns the calling thread's identifier.

• int pthread_join(pthread_t thread, void **value_ptr);
  
  

The pthread_join subroutine blocks the calling thread until the thread specified in the call terminates. The target thread's termination status is returned in the status parameter. If the target thread is already terminated, but not yet detached, the subroutine returns immediately. It is impossible to join a detached thread, even if it is not yet terminated. The target thread is automatically detached after all joined threads have been woken up. This subroutine does not itself cause a thread to be terminated. It acts like the pthread_cond_wait subroutine to wait for a special condition. "Joining" is one way to accomplish synchronization between threads as shown in the figure 5.

Figure 5. Typical master and worker - Pthread Programming model

• int pthread_detach(pthread_t thread, void **value_ptr);
  
  

Detaches the specified thread from the calling thread.
The pthread_detach subroutine is used to indicate to the implementation that storage for the thread whose thread identifier is in the location thread can be reclaimed When that thread terminates. This storage shall be reclaimed on process exit, regardless of whether the thread has been detached or not, and may include storage for thread return value. If thread has not yet terminated, pthread_detach shall not cause it to terminate. Multiple pthread_detach calls on the same target thread causes an error.

If the target thread is already terminated, but not yet detached, the subroutine returns immediately. It is impossible to join a detached thread, even if it is not yet terminated. The target thread is automatically detached after all joined threads have been woken up. This subroutine does not itself cause a thread to be terminated. It acts like the pthread_cond_wait subroutine to wait for a special condition.

• int pthread_mutex_init (pthread_mutex_t *mutex, pthread_mutexattr_t *attr);
  
  

Initializes a mutex and sets its attributes.
The pthread_mutex_init subroutine initializes a new mutex , and sets its attributes according to the mutex attributes object attr. The mutex is initially unlocked.
After initialization of the mutex, the mutex attributes object can be reused for another mutex initialization, or deleted.

• int pthread_mutex_destroy(pthread_mutex_t *mutex);
  
  

Deletes a mutex. The pthread_mutex_destroy subroutine deletes the mutex mutex. After deletion of the mutex, the mutex parameter is not valid identifier until it is initialized again by a call to the pthread_mutex_init subroutine.

• int pthread_mutex_lock (pthread_mutex_t *mutex);
  
  

Locks a mutex. Calling pthread_mutex_lock locks the mutex object referenced by mutex. If the mutex is already locked, the calling thread blocks until the mutex becomes available. This operation returns with the mutex object referenced by mutex in the locked state with the calling thread as its owner.

9.pthread_mutex_trylock:

• int pthread_mutex_trylock (pthread_mutex_t *mutex);
  
  

Tries to lock a Mutex. The function pthread_mutex_trylock is identifierentical to pthread_mutex_lock except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call returns immediately.

• int pthread_mutex_unlock (pthread_mutex_t *mutex); <
  
  

Unlocks a Mutex. The pthread_mutex_unlock function releases the mutex object referenced by mutex. The manner in which a mutex is released is dependent upon the mutex's type attribute. If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock is called, resulting in the mutex becoming available, the scheduling policy is used to determine which thread shall acquire the mutex.

Pthreads code should include the pthread.h header file. On the compilation command line, the Pthreads library should be specified to the linker on UNIX and Linux environments using the -lpthread command-line switch.

The specific files to be used will differ with implementation on various platforms.

There are two ways to compile pthread codes :

The compilation and execution details of Pthreads programs will vary from one system to another. The essential steps are common to all the systems.

Use gcc on most of the systems. First for compiliation, we should use following statement :

For more control over the process of compiling and linking programs for Pthreads, you should use a ' Makefile '. You may also use some commands in Makefile particularly for programs contained in a large number of files. The user has to specify the names of the program and appropriate paths to link some of the libraries required for Pthreads programs in the Makefile.
To compile and link a Pthreads program, type the command,

To execute a Pthreads Program, give the name of the executable at command prompt.

$ . / < Name of the Executable >

For example, to execute a simple HelloWorld Program, user must type:

$ ./helloworld

The output must look similar to the following:

In the tar file which we have provided on our web-page you will find one README file. That file contains all information about how to compile and execute benchmark. Here we are providing brief summary of how to compile and execute benchmark:

First, you need to go in the directory named In-House-Pthreads-Benchmarks

In order to execute you should give :

To Execute the above Programs on MPI based Cluster (with Job Management sofware), the user should submit job to scheduler. To submit the job use the following command.

For Example :

bsub -q normal -ext"SULRM[nodes=1]" -o pthread-hello-world.out -e
           pthread-hello-world.err ./pthread-helloworld

NOTE :

          1). Where "pthread-helloworld" is binary executable of pthread-helloworld.c program.
          2). "nodes=1" indicates number of nodes required to run the executable.
          3). Refer man pages of "bsub" for options.

It is important to understand common problem before designing a multi-threaded algorithms on Multi-Core Systems.

• Set up all the requirements for a thread before actually creating the thread. This includes initializing the data, setting thread attributes, thread priorities, mutex attributes etc Once you create a thread,it is possible that newly created thread actually runs for completion before the creating thread gets scheduled again.

• Once you create a thread, it is possible that the newly created thread actually runs to complete before the creating thread gets scheduled again.

• When there is a relation between two threads : (Producer - Consumer relation ) for certain data items, make sure that one thread places the data before it is consumed and that intermediate buffers are guaranteed to not overflow. (Example : Producer - Consumer )

• At the Consumer end, make sure that the data lasts until all potential consumers have consumed the data. This is particularly relevant for stack variables.

• When possible, define and use group synchronization and data replication. This can improve program performance significantly.

• Extreme causation must be taken to avoid race condition and parallel overheads associated with synchronization.

• Too many threads can seriously degrade program performance.
  The impact comes in two ways. First partitioning a fixed amount of work among too many threads and this may give too little work for each thread. This leads to overhead of starting and terminating threads swamps the useful work. Second, having too many concurrent software threads incurs overheads from having to share fixed hardware resources.

• Spawning application software threads than hardware threads, the OS typically resorts to round robin scheduling. The scheduler gives each software a short turn, called a time slice to run on one of the hardware threads. Too many software threads, thread's time slice, run the hardware thread may incur overhead, resulting performance degradation.

• With emergence of cache on each core, the access time from cache memory is 10 to 100 times faster than main memory and the data access that hit in cache are fast. They do not consume bandwidth of the memory bus. This may lead to conflict of data sharing and the net effect is too many threads hurt performance while they share the data in cache. Thus the time slicing causes threads to fight each other for real memory and thus hurts the performance.

• A similar overhead at a different level, is thrashing virtual memory. Most systems use virtual memory, where the processors have an address space bigger than the actual available memory. Virtual memory resides on disk and the frequently used portions are kept in real memory. For a large problem size, too many threads lead to exceed even virtual memory.

• Thread lock implementation is another issue in which all the threads may wait to acquire a lock and it is closely related to thread time slicing. In some situations, all the threads waiting for the lock must now wait for the holding thread to wake-up and release the lock. This leads to an additional overhead as the threads wait behind (blocking effect).

• Runnable threads, not blocked threads, cause time-slicing, overhead. When a thread is blocked waiting for an external event, such as disk I/O request, the OS takes it off the round-robin schedule. Here, a blocked thread does not cause time-slicing overhead and a program may have more software threads than hardware threads, and still run efficiently if most of the OS threads are blocked. The concept of compute threads & I/O threads may help to reduce the overheads. Special care is needed to ensure that the compute threads should match the
  processor resources.

• Unsynchronized access to shared memory can introduce race conditions. This may happen due to Data Races, Deadlocks, and Live Locks. Race condition are typically a lock the protects the invariant that might otherwise be violated by interleaved operations. Deadlocks are often associated with locks, it can happen any time a thread tires to acquire Exclusive access to two or more shared resources. Proper use of lock avoid race conditions can invite performance problems if the lock becomes highly contended.

• Non-blocking algorithms can address the lock problems partially but it introduces overheads due to atomic operations . For many applications, the non-blocking algorithms cause a lot of traffic on the memory bus as various hardware threads keep trying and retrying to perform operations on the same cache line.

• Thread-safe functions and Libraries: The routines should be thread safe; that is, concurrently, callable by clients. The complete thread safety is not requires and it may introduce additional overheads because every call is forced to some locking, and performance would be not satisfactory. A mechanism is required when the threads are called concurrently to in-corporate thread safety.

• The other issues such as memory contention and conserver band-width and working in the cache. The memory contention on mutli-core processors is difficult to understand. The applications which require to work within cache becomes complex because the data is not only transferred between a core and memory, but also between cores. The transfer of data aris implicitly from patterns of reads and write by different cores. The patterns correspond to two types of data-dependencies (Read-write dependency; Write-write dependency).

• The performance of program depends on processors fetching most of their data from cache instead of main memory. When two threads increments a different location belonging to the same cache line, the cores must pass the sector back and forth across the memory bus. The performance merely depends upon the locations whether they are adjacent or not on the same cache line. Aligning false sharing is required and it can be done by aligning variables or objects in memory on cache line boundaries.

A thread is a stream of instructions that can be scheduled as an independent unit. A thread exists within a process, and uses the process resources. Since threads are very small compared with processes, thread creation is relatively cheap in terms of CPU costs.

A Thread is an encapsulation of the flow of control in a program. Most people are used to writing single-threaded programs - that is,programs that only execute one path through their code "at a time". Multithreaded programs may have several threads running through different code paths "simultaneously".

A context switch between two threads in a single process is considerably cheaper than a context switch between two processes. In addition, the fact that all data except for stack and registers are shared between threads makes them a natural vehicle for expressing tasks that can be broken down into subtasks that can be run cooperatively.

Pthreads stands from POSIX Threads. POSIX threads, based on the IEEE POSIX 1003.1c-1995 (also known as the ISO/IEC 9945-1:1996) standard, part of the ANSI/IEEE 1003.1, 1996 edition, standard.The Pthreads library is a POSIX C API thread library that has standardized functions for using threads across different platforms. It is a set of threading interfaces developed by IEEE Committee in charge of specifying a portable operating system interface(POSIX). POSIX committee defined a basic set of functions and data structures that it hoped would have been used by numerous vendors so that threaded code can be ported easily across operating systems.It specifies API to handle most of actions required by threads.It is a library that has standardized functions for using threads across different platforms.

A lightweight process (also known in some implementations, confusingly, as a kernel thread) is a schedulable entity that the kernel is aware of. On most systems, it consists of some execution context and some accounting information (i.e. much less than a full-blown process).
Several operating systems allow lightweight processes to be "bound" to particular CPUs; this guarantees that those threads will only execute on the specified CPUs.

If some piece of code is described as MT-safe, this indicates that it can be used safely within a multithreaded program, and that it supports a "reasonable" level of concurrency. This isn't very interesting; what you, as a programmer using threads, need to worry about is code that is not MT-safe. MT-unsafe code may use global and/or static data. If you need to call MT-unsafe code from within a multithreaded program, you may need to go to some effort to ensure that only one thread calls that code at any time. Wrapping a global lock around MT-unsafe code will generally let you call it from within a multithreaded program, but since this does not permit concurrent access to that code, it is not considered to make it MT-safe.

Scheduling involves deciding what thread should execute next on a particular CPU. It is usually also taken as involving the context switch to that thread.

There are two main kinds of threads implementations:

User-space threads live without any support from the kernel; they maintain all of their state in user space. Since the kernel does not know about them, they cannot be scheduled to run on multiple processors in parallel.

Kernel-supported threads fall into two classes. In a "pure" kernel-supported system, the kernel is responsible for scheduling all threads. Systems in which the kernel cooperates with a user-level library to do scheduling are known as two-level, or hybrid, systems. Typically, the kernel schedules LWPs, and the user-level library schedules threads onto LWPs. Because of its performance problems (caused by the need to cross the user/kernel protection boundary twice for every thread context switch), the former class has fewer members than does the latter (at least on Unix variants). Both classes allow threads to be run across multiple processors in parallel.

In terms of context switch time, user-space threads are the fastest, with two-level threads coming next (all other things being equal). However, if you have a multiprocessor, user-level threads can only be run on a single CPU, while both two-level and pure kernel-supported threads can be run on multiple CPUs simultaneously.

Because the kernel does not know about user threads, there is a danger that ordinary blocking system calls will block the entire process (this is bad) rather than just the calling thread. This means that user-space threads libraries need to jump through hoops in order to provide "blocking" system calls that don't block the entire process. This problem also exists with two-level kernel-supported threads, though it is not as acute as for user-level threads. What usually happens here is that system calls block entire LWPs. This means that if more threads exist than do LWPs and all of the LWPs are blocked in system calls, then other threads that could potentially make forward progress are prevented from doing so.

The Solaris threads library provides a reasonable solution to this problem. If the kernel notices that all LWPs in a process are blocked, it sends a signal to the process. This signal is caught by the user-level threads library, which can create another LWP so that the process will continue to make progress.