*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> pthreads (5)              
Title
Content
Arch
Section
 

Contents


pthreads(5)							   pthreads(5)


NAME    [Toc]    [Back]

     pthreads -	introduction to	POSIX thread characteristics

DESCRIPTION    [Toc]    [Back]

     This man page is intended as an overview of the POSIX thread model	as
     implemented in IRIX; it is	not an introduction to thread programming or a
     detailed description of the IRIX implementation.

     Thread programming	is motivated by	two concerns:

     Application Performance    [Toc]    [Back]
	  o   On a multiprocessor multiple threads may run at the same time.
	  o   Operations that cause the	caller to wait do not prevent other
	      threads (in the same process) from making	progress.

     Programming Model    [Toc]    [Back]
	  o   Complex applications can be structured more elegantly by
	      partitioning with	threads.
	  o   Threads share many resources implicitly which can	simplify cooperative
	algorithms.

     In	the past a UNIX	process	has been thought of as having a	single thread.
     The POSIX thread programming model	(known as pthreads) introduces the
     concept of	multiple threads within	a single process.  A POSIX thread is
     an	executable entity that belongs to a process.  It contains sufficient
     state to enable it	to run on a processor independently of its fellows.
     In	most other respects threads share state	with their host	process.  The
     vast majority of interfaces and features work the same way	in a multithreaded
 process as an unthreaded one.

     The POSIX threads API provides a set of interfaces	and semantics for
     creating and controlling threads.	Because	the interfaces are defined by
     the ISO standards organisation an application using them may enjoy	the
     benefits of parallel programming without sacrificing portability.

   Applications    [Toc]    [Back]
     To	create a pthread process an application	must be	linked with the
     pthread run-time library.	It is also recommended that the	thread safe
     options be	enabled	at compile time	using the feature test macro,
     _POSIX_C_SOURCE.

	  cc -D_POSIX_C_SOURCE=199506L app.c -llib0 -llib1 ... -lpthread

     See intro(3), section 3P for further details.

   Components    [Toc]    [Back]
     POSIX threads introduces a	number of thread components.

     Attribute    [Toc]    [Back]
	  An attribute is a characteristic of something	that defines its
	  behaviour.  Most of the objects introduced by	pthreads have
	  characteristics which	are set	when it	is created; indeed some



									Page 1






pthreads(5)							   pthreads(5)



	  characteristics may only be set at that time.	 A set of
	  characteristics may be specified in an attribute object which	is
	  passed to the	creation interface.  An	analogy	is a mould or template
	  that is used to shape	some artifact.	Every attribute	has a default
	  value	and the	attribute object itself	is optional.

     Thread    [Toc]    [Back]
	  A thread executes code.  It is created using pthread_create()	and
	  either inherits characteristics from its creator or has them
	  specified via	creation attributes.  The pthread_attr_* interfaces
	  may be used to create	a thread attributes object.
	  Many features	of the process are shared by its threads, including
	  process and user ids (PID, UID), file	descriptors, memory (including
	  text and data) and signal handlers.
	  Each thread has a unique identity which is used by a number of
	  pthread interfaces.  Thread ids may be compared using
	  pthread_equal().
	  Threads terminate with an exit status	[see pthread_exit()].  By
	  default the thread identity and exit status persist after the	thread
	  has terminated until the status is retrieved using pthread_join().
	  An application should	either retrieve	this status or arrange for it
	  to be	automatically discarded	on thread termination using
	  pthread_detach() or setting the detach thread	attribute.

     Mutex Lock    [Toc]    [Back]
	  A mutex lock facilitates exclusive access by a thread	to a resource.
	  Only one thread may own a mutex at a time and	is thus	guaranteed
	  exclusive access.
	  Mutex	interfaces are described on the	pthread_mutex_*	man pages.
	  The pthread_mutexattr_* interfaces may be used to create a mutex
	  attributes object.  Attributes include error checking, recursion and
	  owner	priority.  Mutexes are intended	to be lightweight and only
	  owned	for brief periods of time.

     Condition Variable    [Toc]    [Back]
	  A condition variable synchronises threads with an event of interest.
	  Condition variables allow a thread to	wait for an event and be woken
	  up when the event occurs; the	nature of the event is determined by
	  the application.
	  Condition variable interfaces	are described on the pthread_cond_*
	  man pages.  The pthread_condattr_* interfaces	may be used to create
	  a condition variable attributes object.

     Read-Write	Lock
	  A read-write lock facilitates	shared access for read and exclusive
	  access for write by threads to a resource.  They are used in
	  conjunction with resources which are frequently read but
	  infrequently changed (written).
	  Read-write lock interfaces are described on the pthread_rwlock_* man
	  pages.  The pthread_rwlockattr_* interfaces may be used to create a
	  read-write lock attributes object.




									Page 2






pthreads(5)							   pthreads(5)



     Semaphore    [Toc]    [Back]
	  A semaphore synchronises threads with	a counter.  Semaphores are not
	  part of pthreads per se and do not have an associated	attributes
	  object.  However anonymous semaphores	provide	a pshared flag (for
	  semaphores which are private to the process) which allows pthreads
	  to optimise access [see sem_init(3C)].  Semaphore interfaces are
	  described on the sem_* man pages.

   Semantics    [Toc]    [Back]
     POSIX threads introduces the following special semantics.

     Cancellation    [Toc]    [Back]
	  A cancellation request is a request for a thread to terminate.  Each
	  thread specifies whether and when to act on cancellation requests
	  using	its cancelability state	and type.  A request is	made with
	  pthread_cancel() and the state and type are set with
	  pthread_setcancelstate() and pthread_setcanceltype().	 Termination
	  handlers may be established to execute code when a thread terminates
	  for some reason including acting on a	cancellation request.

     Signals    [Toc]    [Back]
	  In the pthread signal	model all threads share	the signal disposition
	  [see sigaction(2)] but each thread has its own signal	mask of
	  blocked signals.  Signals may	be sent	to individual threads using
	  the pthread_kill() interface.	 Each thread may change	its own	mask
	  using	pthread_sigmask().  In IRIX, sigprocmask(2) is equivalent to
	  pthread_sigmask() but	a portable pthread application should only use
	  the latter.
	  A signal is delivered	to at most one thread; it is not broadcast to
	  all threads.

	  o   When a signal is directed	at a process the first eligible	thread
	      is chosen	to receive it.	An eligible thread is one that does
	      not have the signal blocked in its signal	mask or	is waiting in
	      sigwait(3).  If there are	no eligible threads then the signal
	      remains pending on the process until a thread becomes eligible.
	      This is called asynchronous signal delivery; kill(2) causes this
	      type of delivery.

	  o   When a signal is directed	at a thread then that thread will
	      receive it.  If the signal is blocked then it will remain
	      pending on the target thread; it will not	be delivered to	a
	      different	thread.	 This is called	synchronous signal delivery;
	      exceptions and program faults cause this type of delivery.

	  o   If the action of the signal is to	stop, continue or terminate
	      the recipient then it will act on	the process as a whole.	 It is
	      not possible to stop, continue or	terminate a single thread with
	      a	signal.






									Page 3






pthreads(5)							   pthreads(5)



     Notifications    [Toc]    [Back]
	  An extension to signal handling for threads is the addition of
	  SIGEV_THREAD which creates a thread instead of sending a signal as a
	  means	of handling the	occurrence of some event [see mq_notify(3C),
	  aio_read(3) and timer_create(3C)].  Creation of the thread takes
	  place	when the event occurs so care should be	taken to avoid any
	  errors or else the notification may be lost.

     Scheduling    [Toc]    [Back]
	  When a processor executes instructions on behalf of a	user it	does
	  so according to a set	of scheduling attributes which are part	of a
	  kernel execution vehicle.  Every thread that executes	on a processor
	  or waits in the kernel needs such a vehicle.

	  POSIX	threads	makes a	distinction between system scope (kernel)
	  scheduling and process scope (run-time) scheduling. The SGI
	  implementation adds an additional scheduling scope, bound scope.
	  These	bound scope threads are	scheduled exactly the same as POSIX
	  process scope	threads.  For the rest of this man page, the
	  discussion of	process	scope scheduling is applicable for bound scope
	  threads.  In both scopes the individual thread scheduling policy and
	  priority values are set using	the interfaces
	  pthread_attr_setschedpolicy(), pthread_attr_setschedparam(), and
	  pthread_setschedparam().

	  Scope	is defined when	a thread is created using
	  pthread_attr_setscope():

	  system scope threads are scheduled by	the kernel; the	scheduling
	  attributes of	the thread and the kernel execution vehicle are	the
	  same.	 The kernel includes all system	scope threads in its
	  scheduling decisions.	 These threads run at realtime policy and
	  priority and may only	be created by privileged users.

	  process scope	threads	are scheduled by the pthread run-time; the
	  scheduling attributes	of the thread and the kernel execution vehicle
	  may be different.  The run-time makes	scheduling decisions based
	  only on the process scope threads in the host	process.

	  An advantage of system scope is that a thread	can get	high
	  performance and deterministic	response.  A disadvantage is that
	  kernel resources must	be allocated to	each thread.

	  In contrast, process scope threads only require kernel state when
	  they are executing on	a processor or waiting in the kernel.  The
	  run-time scheduler multiplexes process scope threads onto a smaller
	  number of kernel execution vehicles.	This can produce faster
	  scheduling because no	kernel state is	involved.

	  The number of	execution vehicles used	for process scope threads
	  depends on application behaviour and system configuration.  By
	  default, the run-time	adjusts	this number dynamically	but the



									Page 4






pthreads(5)							   pthreads(5)



	  pthread_setconcurrency() interface gives a strong hint as to the
	  desired value.

	  The execution	vehicles used for process scope	threads	share a	set of
	  kernel scheduling attributes which can be changed using the
	  sched_setscheduler() and sched_setparam() interfaces.	 These
	  interfaces do	not affect system scope	thread scheduling.  As with
	  system scope threads changing	these scheduling attributes is a
	  privileged operation.

     Low-overhead Locking    [Toc]    [Back]
	  In order to protect updates to internal pthread data structures, a
	  low-overhead locking mechanism is required.  This locking interface
	  is not user-callable and is contained	entirely within	the pthread
	  library.  When pthreads are present, this locking mechanism is also
	  used to ensure that some routines in libc can	be safely called from
	  multiple threads.  Some examples of this are the stdio(3S) routines
	  and the malloc(3C) routines.

	  By default, these locks spin/sleep for process scope and bound scope
	  threads on multiprocessor systems, and immediately block for system
	  scope	threads	and on single processor	systems.  In the spin/sleep
	  lock path, the lock will be tried 1000 times,	and then nanosleep(2)
	  will be called.  This	process	will be	repeated until the lock	can be
	  obtained.

	  This process can be tuned for	an individual application with the
	  PT_SPINS environment variable.  This determines how many times the
	  lock is tried	before sleeping.  This environment variable is checked
	  once at program startup time.	 Different spin	values may be used to
	  improve application throughput; however, higher values will probably
	  increase user	time while lower values	will probably increase system
	  time.	 In general, applications with more pthreads than processors
	  will probably	benefit	from setting PT_SPINS to a lower value,	while
	  applications with fewer pthreads may benefit from setting the
	  environment variable to a higher value.  If the environment variable
	  is set to 0, these locks will	all become blocking locks.
	  realtime(5) applications and applications that create	only system
	  scope	threads	may benefit from setting PT_SPINS to 0.	 This forces
	  the locks to block immediately instead of having the lock routine do
	  a run-time check to determine	if the caller is a system scope
	  thread.

     Thread Data    [Toc]    [Back]
	  Pthreads share the address space; stacks, text and data are
	  accessible by	all threads in the process.  This means	that access to
	  shared data is simpler than where multiple processes use a shared
	  memory region	which each must	map.  The cost is the potential	for
	  accidental corruption.  Individual thread data is provided using the
	  notion of a shared set of keys and unique thread values bound	to
	  each key.  The pthread_key_create() interface	creates	a new, shared
	  key and pthread_setspecific()	allows a thread	to bind	its own	value



									Page 5






pthreads(5)							   pthreads(5)



	  to a key.  Conceptually, the key is an index to an array of values.
	  The same key used by different threads may retrieve a	different
	  values because each thread has its own array.

     Process Management    [Toc]    [Back]
	  Some basic UNIX interfaces have particular semantics when called
	  from a POSIX threads process.

	  fork(2) creates a new	pthread	process	and follows the	usual rules
	  for inherited	state.	The new	process	has a single pthread (the one
	  which	made the call);	all other pthreads active prior	to fork() are
	  quietly destroyed and	their resources	(stacks	etc.) reclaimed	by the
	  pthread run-time.  A number of issues	arise because fork() causes
	  data to be copied from the parent to the child with no
	  synchronisation with threads that may	be modifying that data.	 To
	  allow	the application	to perform its own synchronisation the
	  pthread_atfork() interface can register handlers to be processed
	  when fork() is used.	In general operations which are	safe to
	  perform after	a fork() are the same as those which are safe to
	  perform in a signal handler.

	  exec(2) overlays a new process image on the calling process; all
	  threads from the old image are destroyed.  Thread termination
	  handlers and thread data destruction	[see pthread_cleanup_push()
	  and pthread_key_create()] are	not performed.	The new	process	will
	  only be a pthread process if the new image is	of a pthread process.

	  exit(2) performs all the usual process clean up operations and then
	  destroys all threads in the process.	Thread termination handlers
	  and thread data destruction  [see pthread_cleanup_push() and
	  pthread_key_create()]	are not	performed.

   Limitations    [Toc]    [Back]
     With POSIX	threads	there are some limitations and practices to avoid.

     Not enough	pthreads
	  Each pthread process has a resource limit called RLIMIT_PTHREAD on
	  the number of	threads	it can create.	The value is inherited by
	  child	processes and may be set using setrlimit(2) or the shell limit
	  and ulimit commands.	The default limits can be changed using	the
	  systune(1M) command on the rlimit_pthread_cur	and rlimit_pthread_max
	  variables.

     Fatal exceptions    [Toc]    [Back]
	  When a thread	executes code in the pthread run-time scheduler	it
	  masks	signals	so that	signal handlers	always run in a	consistent
	  environment.	A side effect of this is that if the thread raises an
	  exception (for example due to	memory corruption) the kernel will
	  terminate the	process.  As an	aid to debugging such problems the
	  environment variable PT_CORE should be set prior to starting the
	  application so that a	core file will be generated.




									Page 6






pthreads(5)							   pthreads(5)



     Stack overrun    [Toc]    [Back]
	  Unlike the default stack in an unthreaded IRIX process, pthread
	  stacks are limited [see pthread_attr_setstacksize()] and a thread
	  may overrun its stack.  By default pthread stacks have a protected
	  region at the	end of the stack [see pthread_attr_setguardsize()]
	  that can turn	some of	these overruns into a protection faults	which
	  is generally preferable to overwriting data.

     Dynamic loading    [Toc]    [Back]
	  The pthread library can be made available to a running process. The
	  pthread DSO can be dynamically loaded	using dlopen(3C) or
	  sgidladd(3C).	 Any pthread calls made	before pthread library is
	  loaded will all return ENOSYS.

     Using sprocs    [Toc]    [Back]
	  The sproc(2) model of	threading is incompatible with POSIX threads.
	  Attempts by an sproc process to create pthreads and vice-versa will
	  be rejected.

     Priority    [Toc]    [Back]
	  Attempts to create a pthread process at a priority outside of	the
	  valid	range will be rejected [see sched_get_priority_min(2) and
	  sched_get_priority_max(2)].  Specifically, weightless	is not a valid
	  pthread priority.

     MAP_LOCAL memory    [Toc]    [Back]
	  The POSIX thread memory model	requires that memory be	available to
	  all threads.	The MAP_LOCAL option to	mmap(2)	is useful only to
	  sproc	processes and should not be used with pthreads.

     Dynamic memory allocation    [Toc]    [Back]
	  The sbrk(2) call is not thread-safe.	It is used by the C run-time
	  memory allocator, malloc(3C),	which is always	used by	the pthread
	  run-time.  Safe use of sbrk(2) outside of the	run-time (for example
	  by a third party memory allocator) is	not therefore possible.

   Documentation    [Toc]    [Back]
     Additional	on-line	documentation about pthreads is	available in:
	  Topics in IRIX Programming: Chapter 13
	  SpeedShop User's Guide: Chapter 6

SEE ALSO    [Toc]    [Back]

      
      
     pthread_*(3P)


									PPPPaaaaggggeeee 7777
[ Back ]
 Similar pages
Name OS Title
pthread FreeBSD POSIX thread functions
acl FreeBSD introduction to the POSIX.1e ACL security API
posix1e OpenBSD introduction to the POSIX.1e security API
pthread_intro Tru64 Introduction to POSIX Threads
pthread Tru64 Introduction to POSIX Threads
posix1e FreeBSD introduction to the POSIX.1e security API
intro_pxf IRIX Introduction to PXF POSIX library
pthreads OpenBSD POSIX 1003.1c thread interface
sigpending IRIX return set of signals pending for thread (POSIX)
tis Tru64 Introduction to Thread-Independent Services (tis)
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service