Pthreads - revision history

Dank: /* Condition variable clocks */

2021-10-21T18:45:49Z

Condition variable clocks

← Older revision		Revision as of 18:45, 21 October 2021
Line 22:		Line 22:

	==Condition variable clocks==		==Condition variable clocks==
	By default, <tt>pthread_cond_timedwait()</tt> uses <tt>CLOCK_REALTIME</tt>, with all its attendant problems. You probably want it to use <tt>CLOCK_MONOTONIC</tt>. This can be effected on some implementations using <tt>pthread_condattr_setclock()</tt>.		By default, <tt>pthread_cond_timedwait()</tt> uses <tt>CLOCK_REALTIME</tt>, with all its attendant problems. You probably want it to use <tt>CLOCK_MONOTONIC</tt>. This can be effected on some implementations using <tt>pthread_condattr_setclock()</tt>. The new function <tt>pthread_cond_clockwait()</tt> has been [https://www.austingroupbugs.net/view.php?id=1216 proposed], but not yet accepted into the POSIX standard. Note that C++'s <tt>std::condition_variable</tt> also [https://reviews.llvm.org/D65339 suffers] from this braindamage.

	==Pthreads signal model==		==Pthreads signal model==

Dank: use of clock_realtime is a sin against god and man

2021-10-21T18:34:09Z

use of clock_realtime is a sin against god and man

← Older revision		Revision as of 18:34, 21 October 2021
Line 20:		Line 20:
	* Before trying to solve an issue with POSIX thread scheduling parameters, see if you can't just drink some hydrochloric acid.		* Before trying to solve an issue with POSIX thread scheduling parameters, see if you can't just drink some hydrochloric acid.
	* No, you shouldn't be using the [http://www.mjmwired.net/kernel/Documentation/volatile-considered-harmful.txt volatile keyword].		* No, you shouldn't be using the [http://www.mjmwired.net/kernel/Documentation/volatile-considered-harmful.txt volatile keyword].

			==Condition variable clocks==
			By default, <tt>pthread_cond_timedwait()</tt> uses <tt>CLOCK_REALTIME</tt>, with all its attendant problems. You probably want it to use <tt>CLOCK_MONOTONIC</tt>. This can be effected on some implementations using <tt>pthread_condattr_setclock()</tt>.

	==Pthreads signal model==		==Pthreads signal model==
	POSIX threads specify that all threads within a process share a PID, and that each has its own, distinct thread id. PIDs have the integer type <tt>pid_t</tt>, and only positive PIDs can define actual processes. TIDs have the opaque type <tt>pthread_t</tt>; they cannot be ordered, but can be compared for equality.		POSIX threads specify that all threads within a process share a PID, and that each has its own, distinct thread id. PIDs have the integer type <tt>pid_t</tt>, and only positive PIDs can define actual processes. TIDs have the opaque type <tt>pthread_t</tt>; they cannot be ordered, but can be compared for equality.

	Other processes can direct signals only to a PID, not the thread IDs within another process (TIDs of a given process have no meaning outside that process). Within the process, signals can be directed to particular TIDs. Use of <tt>raise(s)</tt> in a threaded program is equivalent to <tt>pthread_kill(pthread_self(),s)</tt>.		Other processes can direct signals only to a PID, not the thread IDs within another process (TIDs of a given process have no meaning outside that process). Within the process, signals can be directed to particular TIDs. Use of <tt>raise(s)</tt> in a threaded program is equivalent to <tt>pthread_kill(pthread_self(), s)</tt>.

	Signal dispositions (handlers) are per-process. Signal masks are per-thread, and inherited upon thread creation (<tt>sigprocmask()</tt> is undefined in threaded programs; <tt>pthread_sigmask()</tt> must be used). Alternate signal stacks descriptors are per-thread, and inherited upon thread creation.		Signal dispositions (handlers) are per-process. Signal masks are per-thread, and inherited upon thread creation (<tt>sigprocmask()</tt> is undefined in threaded programs; <tt>pthread_sigmask()</tt> must be used). Alternate signal stacks descriptors are per-thread, and inherited upon thread creation.

Dank at 00:16, 19 June 2012

2012-06-19T00:16:39Z

← Older revision		Revision as of 00:16, 19 June 2012
Line 168:		Line 168:
	* the [[LinuxThreads]] port (devel/linuxthreads; this does NOT require emulators/linux-base*)		* the [[LinuxThreads]] port (devel/linuxthreads; this does NOT require emulators/linux-base*)
	all threaded code muse use the reentrant version of the gcc builtin libs; this is done via -lgcc_r (-pthread should set this up). In addition, use -llthread to link against [[LinuxThreads]].		all threaded code muse use the reentrant version of the gcc builtin libs; this is done via -lgcc_r (-pthread should set this up). In addition, use -llthread to link against [[LinuxThreads]].

			==Use with [[autotools]]==
			The <tt>AX_PTHREAD</tt> [http://www.gnu.org/software/autoconf-archive/ax_pthread.html macro] from the Autoconf Archive is canonical, defining <tt>PTHREAD_LIBS</tt>, <tt>PTHREAD_CFLAGS</tt>, and <tt>PTHREAD_CC</tt>.

Dank: /* Dank's Sagelike Wisdom Concerning POSIX Threads */

2011-09-06T14:29:35Z

Dank's Sagelike Wisdom Concerning POSIX Threads

← Older revision		Revision as of 14:29, 6 September 2011
Line 7:		Line 7:
	* The Triforce of POSIX Thread stacks:		* The Triforce of POSIX Thread stacks:
	** If you aren't allocating a stack fit to your thread, you will one day smash that stack.		** If you aren't allocating a stack fit to your thread, you will one day smash that stack.
	** If you're using your stack, you should probably heap-allocate or use TLS.		** If you're using your stack, you should probably heap-allocate or use [[TLS]].
	** Recursion's all fun and games until your recurse on through to the other side.		** Recursion's all fun and games until your recurse on through to the other side.
	** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/TLS in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!		** Yes, this all applies to an unthreaded program (especially an embedded one), with a critical difference -- memory management is process-based, causing noisy failures in the unthreaded case. Meanwhile, a POSIX thread will happily push a frame down right over his buddy's DTV/[[TLS]] in NPTL (see [http://www.redhat.com/whitepapers/developer/POSIX_Linux_Threading.pdf NPTL], "Memory Allocation"). Have a good time debugging that, champ!
	* Failure to check every return, especially pthread_mutex_destroy(), is cause for [http://en.wikipedia.org/wiki/Tuol_Sleng_Genocide_Museum#The_Security_Regulations many many lashes of electric wire].		* Failure to check every return, especially pthread_mutex_destroy(), is cause for [http://en.wikipedia.org/wiki/Tuol_Sleng_Genocide_Museum#The_Security_Regulations many many lashes of electric wire].
	* Those who fail to designate an alternate signal stack will one day wish they had.		* Those who fail to designate an alternate signal stack will one day wish they had.

Dank at 02:26, 7 January 2010

2010-01-07T02:26:06Z

← Older revision		Revision as of 02:26, 7 January 2010
Line 45:		Line 45:
	* [[LinuxThreads]] on 2.2+: Same as NPTL, but three signal numbers are consumed.		* [[LinuxThreads]] on 2.2+: Same as NPTL, but three signal numbers are consumed.
	* [[LinuxThreads]] before 2.0: SIGUSR1 and SIGUSR2 are used. The program must avoid use of SIGUSR1 and SIGUSR2 in either numeric or symbolic form.		* [[LinuxThreads]] before 2.0: SIGUSR1 and SIGUSR2 are used. The program must avoid use of SIGUSR1 and SIGUSR2 in either numeric or symbolic form.
			===[[LinuxThreads]] signals===
			[[LinuxThreads]] (or more accurately, <tt>clone()</tt> prior to the introduction of <tt>CLONE_PID</tt>) failed to guarantee shared PIDs among the threads of a process (each got their own). This severely compromised the POSIX signal model. No concept of process-directed signals exists in [[LinuxThreads]], so external signals are directed to one thread. A "signal manager" thread launched by the library watched for threads terminated due to signal disposition, and attempted to kill the others. Killing the signal management thread was possible, and further broke signal delivery. Signals generated by the terminal, or delivered to the process group, were sent to all threads.
	==Compiling code with pthreads==		==Compiling code with pthreads==
	First off, POSIX requires _REENTRANT be defined in the scope of all code run in a multithreaded manner. This is most typically achieved via -D_REENTRANT on the gcc command line. Some gcc versions / target architectures provide a -pthread option which sets -D_REENTRANT (as well as setting up pthread linking), as evidenced below:<pre>Date: Sun, 8 Apr 2007 23:33:23 -0400		First off, POSIX requires _REENTRANT be defined in the scope of all code run in a multithreaded manner. This is most typically achieved via -D_REENTRANT on the gcc command line. Some gcc versions / target architectures provide a -pthread option which sets -D_REENTRANT (as well as setting up pthread linking), as evidenced below:<pre>Date: Sun, 8 Apr 2007 23:33:23 -0400

Dank: /* Compiling code with pthreads */

2010-01-07T02:19:36Z

Compiling code with pthreads

← Older revision		Revision as of 02:19, 7 January 2010
Line 94:		Line 94:
	off to dig through gcc source....</pre>Nonetheless, this is a poorly-documented gcc-specific method; best to always provide -D_REENTRANT explicitly. -D_REENTRANT and other preprocessor directives which affect code selection should always precede -include options to gcc, ie:<pre>gcc -D_REENTRANT -I/usr/local -include pthread.h ...</pre>		off to dig through gcc source....</pre>Nonetheless, this is a poorly-documented gcc-specific method; best to always provide -D_REENTRANT explicitly. -D_REENTRANT and other preprocessor directives which affect code selection should always precede -include options to gcc, ie:<pre>gcc -D_REENTRANT -I/usr/local -include pthread.h ...</pre>

	On FreeBSD's libc (and also possibly with regard to other third-part libraries), it's also necessary to define _THREAD_SAFE, as evidenced below (furthermore, you need _POSIX_PTHREAD_SEMANTICS and _P1003_1B_VISIBLE for reasons I determined long ago and have since forgotten, see the [[GNU ~~make~~\|make]] snippet below --''dank''):<pre>Newsgroups: sys.research.subversion.repper		On FreeBSD's libc (and also possibly with regard to other third-part libraries), it's also necessary to define _THREAD_SAFE, as evidenced below (furthermore, you need _POSIX_PTHREAD_SEMANTICS and _P1003_1B_VISIBLE for reasons I determined long ago and have since forgotten, see the [[GNU Make\|make]] snippet below --''dank''):<pre>Newsgroups: sys.research.subversion.repper
	From: Nick Black <nblack@securecomputing.com>		From: Nick Black <nblack@securecomputing.com>
	Subject: Re: [repper-304] REENTRANT is required by POSIX for any code using pthr		Subject: Re: [repper-304] REENTRANT is required by POSIX for any code using pthr

Dank: /* Compiling code with pthreads */

2010-01-07T02:18:40Z

Compiling code with pthreads

← Older revision		Revision as of 02:18, 7 January 2010
Line 94:		Line 94:
	off to dig through gcc source....</pre>Nonetheless, this is a poorly-documented gcc-specific method; best to always provide -D_REENTRANT explicitly. -D_REENTRANT and other preprocessor directives which affect code selection should always precede -include options to gcc, ie:<pre>gcc -D_REENTRANT -I/usr/local -include pthread.h ...</pre>		off to dig through gcc source....</pre>Nonetheless, this is a poorly-documented gcc-specific method; best to always provide -D_REENTRANT explicitly. -D_REENTRANT and other preprocessor directives which affect code selection should always precede -include options to gcc, ie:<pre>gcc -D_REENTRANT -I/usr/local -include pthread.h ...</pre>

	On FreeBSD's libc (and also possibly with regard to other third-part libraries), it's also necessary to define _THREAD_SAFE, as evidenced below (furthermore, you need _POSIX_PTHREAD_SEMANTICS and _P1003_1B_VISIBLE for reasons I determined long ago and have since forgotten, see the [[make]] snippet below --''dank''):<pre>Newsgroups: sys.research.subversion.repper		On FreeBSD's libc (and also possibly with regard to other third-part libraries), it's also necessary to define _THREAD_SAFE, as evidenced below (furthermore, you need _POSIX_PTHREAD_SEMANTICS and _P1003_1B_VISIBLE for reasons I determined long ago and have since forgotten, see the [[GNU make\|make]] snippet below --''dank''):<pre>Newsgroups: sys.research.subversion.repper
	From: Nick Black <nblack@securecomputing.com>		From: Nick Black <nblack@securecomputing.com>
	Subject: Re: [repper-304] REENTRANT is required by POSIX for any code using pthr		Subject: Re: [repper-304] REENTRANT is required by POSIX for any code using pthr

Dank: /* Internally-used signals */

2010-01-07T02:18:20Z

Internally-used signals

← Older revision		Revision as of 02:18, 7 January 2010
Line 42:		Line 42:
	===Internally-used signals===		===Internally-used signals===
	If the threading library itself uses signals, they might not be safe for use by the application.		If the threading library itself uses signals, they might not be safe for use by the application.
	* NPTL: The first two realtime signals are used. SIGRTMIN is modified in system include files to accommodate this, so there will be no problems so long as signal numbers are never hardcoded.		* [[NPTL]]: The first two realtime signals are used. SIGRTMIN is modified in system include files to accommodate this, so there will be no problems so long as signal numbers are never hardcoded.
	* LinuxThreads on 2.2+: Same as NPTL, but three signal numbers are consumed.		* [[LinuxThreads]] on 2.2+: Same as NPTL, but three signal numbers are consumed.
	* LinuxThreads before 2.0: SIGUSR1 and SIGUSR2 are used. The program must avoid use of SIGUSR1 and SIGUSR2 in either numeric or symbolic form.		* [[LinuxThreads]] before 2.0: SIGUSR1 and SIGUSR2 are used. The program must avoid use of SIGUSR1 and SIGUSR2 in either numeric or symbolic form.

	==Compiling code with pthreads==		==Compiling code with pthreads==

Dank: /* Pthreads signal model */

2010-01-07T02:17:29Z

Pthreads signal model

← Older revision		Revision as of 02:17, 7 January 2010
Line 40:		Line 40:
	===<tt>kill()</tt> special case===		===<tt>kill()</tt> special case===
	When a thread directs a signal to its own process (using <tt>kill(p,s)</tt> where <tt>p == getpid()</tt>), and the calling thread is not blocking the signal, and the signal could not be delivered to any other thread, at least one pending signal (not necessarily s!) must be delivered to the calling thread before <tt>kill()</tt> returns.		When a thread directs a signal to its own process (using <tt>kill(p,s)</tt> where <tt>p == getpid()</tt>), and the calling thread is not blocking the signal, and the signal could not be delivered to any other thread, at least one pending signal (not necessarily s!) must be delivered to the calling thread before <tt>kill()</tt> returns.
			===Internally-used signals===
			If the threading library itself uses signals, they might not be safe for use by the application.
			* NPTL: The first two realtime signals are used. SIGRTMIN is modified in system include files to accommodate this, so there will be no problems so long as signal numbers are never hardcoded.
			* LinuxThreads on 2.2+: Same as NPTL, but three signal numbers are consumed.
			* LinuxThreads before 2.0: SIGUSR1 and SIGUSR2 are used. The program must avoid use of SIGUSR1 and SIGUSR2 in either numeric or symbolic form.

	==Compiling code with pthreads==		==Compiling code with pthreads==

Dank: /* Pthreads signal model */

2010-01-07T02:13:18Z

Pthreads signal model

← Older revision		Revision as of 02:13, 7 January 2010
Line 36:		Line 36:

	POSIX cancellations are dispatched the same way as a thread-directed signal.		POSIX cancellations are dispatched the same way as a thread-directed signal.

			Signals consumed by <tt>sigwait()</tt> are not subsequently delivered, and thus any registered handlers will not be called.
	===<tt>kill()</tt> special case===		===<tt>kill()</tt> special case===
	When a thread directs a signal to its own process (using <tt>kill(p,s)</tt> where <tt>p == getpid()</tt>), and the calling thread is not blocking the signal, and the signal could not be delivered to any other thread, at least one pending signal (not necessarily s!) must be delivered to the calling thread before <tt>kill()</tt> returns.		When a thread directs a signal to its own process (using <tt>kill(p,s)</tt> where <tt>p == getpid()</tt>), and the calling thread is not blocking the signal, and the signal could not be delivered to any other thread, at least one pending signal (not necessarily s!) must be delivered to the calling thread before <tt>kill()</tt> returns.