<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="extensions" page="attributes" subpage="threads"/>
      <!--
           Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: saxon:threads</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title" content="Saxonica: XSLT and XQuery Processing: saxon:threads"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>saxon:threads</h1>
      <p>This attribute may be set on the <code>xsl:for-each</code> instruction. The value must be an integer. When this
attribute is used with Saxon-EE, the items selected by the <code>select</code> expression of the
instruction are processed in parallel, using the specified number of threads.</p>
      <p>The threads are allocated on a round-robin basis: for example if <code>threads="3"</code> is specified, then
the first item will be processed using thread 1, the second using thread 2, the third using thread 3, 
the fourth using thread 1 again, and so on.
These threads are in addition to the main control thread (so there will be 4 threads in total).
Before firing off the processing of the third item, the control thread will read off the results of processing
the first item, and send them to the destination of the <code>xsl:for-each</code> instruction.</p>
      <p>It is possible to specify <code>saxon:threads="1"</code>. In this case all the items in the input will be processed
sequentially, but asynchronously with the thread that reads the items in the input sequence.</p>
      <p>Processing using multiple threads can take advantage of multi-core CPUs. However, there is an overhead, in that the
results of processing each item in the input need to be buffered. The overhead of coordinating multiple threads is proportionally
higher if the per-item processing cost is low, while the overhead of buffering is proportionally higher if the amount of data
produced when each item is processed is high. Multi-threading therefore works best when the body of the <code>xsl:for-each</code>
instruction performs a large amount of computation but produces a small amount of output.</p>
      <p>It is possible to combine multi-threading with sorting. However, the input is first read and sorted synchronously, and
the items in the sorted sequence are then processed in parallel.</p>
      <p>The effect of using extensions that have side-effects (including <code>saxon:assign</code>) in a multi-threaded
loop is undefined (and probably fatal).</p>
      <p>Multi-threaded processing is available only with Saxon-EE. The attribute <code>saxon:threads</code> is ignored
with a warning if Saxon-EE is not in use. Under Saxon-EE it may also be disabled using the configuration option
<code>FeatureKeys.ALLOW_MULTITHREADING</code> or <code>xslt/@allowMultiThreading='false'</code> in the configuration file.
Multi-threaded processing is also disabled if code is compiled with tracing enabled, for example by using the -T option
on the command line or by using an IDE debugger (this is because otherwise, the trace events would be hopelessly intermingled).</p>
      <p>With multi-threaded processing, the output of different <code>xsl:message</code> instructions may appear in an unpredictable order.
However, Saxon ensures that the <code>xsl:message</code> instruction is atomic, so one message will be completed before another starts.
The same is true of the output from the <code>trace()</code> function call.</p>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="../output-extras.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>