Mercurial > hg > sv-dependency-builds

annotate src/fftw-3.3.8/doc/html/Thread-safety.html @ 83:ae30d91d2ffe

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Replace these with versions built using an older toolset (so as to avoid ABI compatibilities when linking on Ubuntu 14.04 for packaging purposes)
author Chris Cannam
date Fri, 07 Feb 2020 11:51:13 +0000
parents d0c2a83c1364
children
rev   line source
Chris@82 1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Chris@82 2 <html>
Chris@82 3 <!-- This manual is for FFTW
Chris@82 4 (version 3.3.8, 24 May 2018).
Chris@82 5
Chris@82 6 Copyright (C) 2003 Matteo Frigo.
Chris@82 7
Chris@82 8 Copyright (C) 2003 Massachusetts Institute of Technology.
Chris@82 9
Chris@82 10 Permission is granted to make and distribute verbatim copies of this
Chris@82 11 manual provided the copyright notice and this permission notice are
Chris@82 12 preserved on all copies.
Chris@82 13
Chris@82 14 Permission is granted to copy and distribute modified versions of this
Chris@82 15 manual under the conditions for verbatim copying, provided that the
Chris@82 16 entire resulting derived work is distributed under the terms of a
Chris@82 17 permission notice identical to this one.
Chris@82 18
Chris@82 19 Permission is granted to copy and distribute translations of this manual
Chris@82 20 into another language, under the above conditions for modified versions,
Chris@82 21 except that this permission notice may be stated in a translation
Chris@82 22 approved by the Free Software Foundation. -->
Chris@82 23 <!-- Created by GNU Texinfo 6.3, http://www.gnu.org/software/texinfo/ -->
Chris@82 24 <head>
Chris@82 25 <title>FFTW 3.3.8: Thread safety</title>
Chris@82 26
Chris@82 27 <meta name="description" content="FFTW 3.3.8: Thread safety">
Chris@82 28 <meta name="keywords" content="FFTW 3.3.8: Thread safety">
Chris@82 29 <meta name="resource-type" content="document">
Chris@82 30 <meta name="distribution" content="global">
Chris@82 31 <meta name="Generator" content="makeinfo">
Chris@82 32 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Chris@82 33 <link href="index.html#Top" rel="start" title="Top">
Chris@82 34 <link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index">
Chris@82 35 <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
Chris@82 36 <link href="Multi_002dthreaded-FFTW.html#Multi_002dthreaded-FFTW" rel="up" title="Multi-threaded FFTW">
Chris@82 37 <link href="Distributed_002dmemory-FFTW-with-MPI.html#Distributed_002dmemory-FFTW-with-MPI" rel="next" title="Distributed-memory FFTW with MPI">
Chris@82 38 <link href="How-Many-Threads-to-Use_003f.html#How-Many-Threads-to-Use_003f" rel="prev" title="How Many Threads to Use?">
Chris@82 39 <style type="text/css">
Chris@82 40 <!--
Chris@82 41 a.summary-letter {text-decoration: none}
Chris@82 42 blockquote.indentedblock {margin-right: 0em}
Chris@82 43 blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
Chris@82 44 blockquote.smallquotation {font-size: smaller}
Chris@82 45 div.display {margin-left: 3.2em}
Chris@82 46 div.example {margin-left: 3.2em}
Chris@82 47 div.lisp {margin-left: 3.2em}
Chris@82 48 div.smalldisplay {margin-left: 3.2em}
Chris@82 49 div.smallexample {margin-left: 3.2em}
Chris@82 50 div.smalllisp {margin-left: 3.2em}
Chris@82 51 kbd {font-style: oblique}
Chris@82 52 pre.display {font-family: inherit}
Chris@82 53 pre.format {font-family: inherit}
Chris@82 54 pre.menu-comment {font-family: serif}
Chris@82 55 pre.menu-preformatted {font-family: serif}
Chris@82 56 pre.smalldisplay {font-family: inherit; font-size: smaller}
Chris@82 57 pre.smallexample {font-size: smaller}
Chris@82 58 pre.smallformat {font-family: inherit; font-size: smaller}
Chris@82 59 pre.smalllisp {font-size: smaller}
Chris@82 60 span.nolinebreak {white-space: nowrap}
Chris@82 61 span.roman {font-family: initial; font-weight: normal}
Chris@82 62 span.sansserif {font-family: sans-serif; font-weight: normal}
Chris@82 63 ul.no-bullet {list-style: none}
Chris@82 64 -->
Chris@82 65 </style>
Chris@82 66
Chris@82 67
Chris@82 68 </head>
Chris@82 69
Chris@82 70 <body lang="en">
Chris@82 71 <a name="Thread-safety"></a>
Chris@82 72 <div class="header">
Chris@82 73 <p>
Chris@82 74 Previous: <a href="How-Many-Threads-to-Use_003f.html#How-Many-Threads-to-Use_003f" accesskey="p" rel="prev">How Many Threads to Use?</a>, Up: <a href="Multi_002dthreaded-FFTW.html#Multi_002dthreaded-FFTW" accesskey="u" rel="up">Multi-threaded FFTW</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
Chris@82 75 </div>
Chris@82 76 <hr>
Chris@82 77 <a name="Thread-safety-1"></a>
Chris@82 78 <h3 class="section">5.4 Thread safety</h3>
Chris@82 79
Chris@82 80 <a name="index-threads-1"></a>
Chris@82 81 <a name="index-OpenMP-3"></a>
Chris@82 82 <a name="index-thread-safety-1"></a>
Chris@82 83 <p>Users writing multi-threaded programs (including OpenMP) must concern
Chris@82 84 themselves with the <em>thread safety</em> of the libraries they
Chris@82 85 use&mdash;that is, whether it is safe to call routines in parallel from
Chris@82 86 multiple threads. FFTW can be used in such an environment, but some
Chris@82 87 care must be taken because the planner routines share data
Chris@82 88 (e.g. wisdom and trigonometric tables) between calls and plans.
Chris@82 89 </p>
Chris@82 90 <p>The upshot is that the only thread-safe routine in FFTW is
Chris@82 91 <code>fftw_execute</code> (and the new-array variants thereof). All other routines
Chris@82 92 (e.g. the planner) should only be called from one thread at a time. So,
Chris@82 93 for example, you can wrap a semaphore lock around any calls to the
Chris@82 94 planner; even more simply, you can just create all of your plans from
Chris@82 95 one thread. We do not think this should be an important restriction
Chris@82 96 (FFTW is designed for the situation where the only performance-sensitive
Chris@82 97 code is the actual execution of the transform), and the benefits of
Chris@82 98 shared data between plans are great.
Chris@82 99 </p>
Chris@82 100 <p>Note also that, since the plan is not modified by <code>fftw_execute</code>,
Chris@82 101 it is safe to execute the <em>same plan</em> in parallel by multiple
Chris@82 102 threads. However, since a given plan operates by default on a fixed
Chris@82 103 array, you need to use one of the new-array execute functions (see <a href="New_002darray-Execute-Functions.html#New_002darray-Execute-Functions">New-array Execute Functions</a>) so that different threads compute the transform of different data.
Chris@82 104 </p>
Chris@82 105 <p>(Users should note that these comments only apply to programs using
Chris@82 106 shared-memory threads or OpenMP. Parallelism using MPI or forked processes
Chris@82 107 involves a separate address-space and global variables for each process,
Chris@82 108 and is not susceptible to problems of this sort.)
Chris@82 109 </p>
Chris@82 110 <p>The FFTW planner is intended to be called from a single thread. If you
Chris@82 111 really must call it from multiple threads, you are expected to grab
Chris@82 112 whatever lock makes sense for your application, with the understanding
Chris@82 113 that you may be holding that lock for a long time, which is undesirable.
Chris@82 114 </p>
Chris@82 115 <p>Neither strategy works, however, in the following situation. The
Chris@82 116 &ldquo;application&rdquo; is structured as a set of &ldquo;plugins&rdquo; which are unaware
Chris@82 117 of each other, and for whatever reason the &ldquo;plugins&rdquo; cannot coordinate
Chris@82 118 on grabbing the lock. (This is not a technical problem, but an
Chris@82 119 organizational one. The &ldquo;plugins&rdquo; are written by independent agents,
Chris@82 120 and from the perspective of each plugin&rsquo;s author, each plugin is using
Chris@82 121 FFTW correctly from a single thread.) To cope with this situation,
Chris@82 122 starting from FFTW-3.3.5, FFTW supports an API to make the planner
Chris@82 123 thread-safe:
Chris@82 124 </p>
Chris@82 125 <div class="example">
Chris@82 126 <pre class="example">void fftw_make_planner_thread_safe(void);
Chris@82 127 </pre></div>
Chris@82 128 <a name="index-fftw_005fmake_005fplanner_005fthread_005fsafe"></a>
Chris@82 129
Chris@82 130 <p>This call operates by brute force: It just installs a hook that wraps a
Chris@82 131 lock (chosen by us) around all planner calls. So there is no magic and
Chris@82 132 you get the worst of all worlds. The planner is still single-threaded,
Chris@82 133 but you cannot choose which lock to use. The planner still holds the
Chris@82 134 lock for a long time, but you cannot impose a timeout on lock
Chris@82 135 acquisition. As of FFTW-3.3.5 and FFTW-3.3.6, this call does not work
Chris@82 136 when using OpenMP as threading substrate. (Suggestions on what to do
Chris@82 137 about this bug are welcome.) <em>Do not use
Chris@82 138 <code>fftw_make_planner_thread_safe</code> unless there is no other choice,</em>
Chris@82 139 such as in the application/plugin situation.
Chris@82 140 </p><hr>
Chris@82 141 <div class="header">
Chris@82 142 <p>
Chris@82 143 Previous: <a href="How-Many-Threads-to-Use_003f.html#How-Many-Threads-to-Use_003f" accesskey="p" rel="prev">How Many Threads to Use?</a>, Up: <a href="Multi_002dthreaded-FFTW.html#Multi_002dthreaded-FFTW" accesskey="u" rel="up">Multi-threaded FFTW</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
Chris@82 144 </div>
Chris@82 145
Chris@82 146
Chris@82 147
Chris@82 148 </body>
Chris@82 149 </html>