Mercurial > hg > sv-dependency-builds

annotate src/fftw-3.3.8/doc/html/Thread-safety.html @ 169:223a55898ab9 tip default

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