<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Hi Jim, in Intel® Moderncode for Parallel Architectures</title>
    <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981702#M5737</link>
    <description>&lt;P&gt;Hi Jim,&lt;/P&gt;
&lt;P&gt;in general RTM does not guarantee that any particular transaction will always succeed (also if retried for many times). For example if there is a page fault on the first access to your buffer -&amp;gt; transaction aborted. Retries do not help because they hit the same issue. Therefore you always need a non-transactional fall-back path (a lock for example):&amp;nbsp;&lt;A href="http://software.intel.com/en-us/blogs/2012/11/06/exploring-intel-transactional-synchronization-extensions-with-intel-software"&gt;http://software.intel.com/en-us/blogs/2012/11/06/exploring-intel-transactional-synchronization-extensions-with-intel-software&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;PS: is line 22 correct? "}&amp;nbsp;if(_xbegin() == _XBEGIN_STARTED)" It seens that xbegins do not match with xends.&lt;/P&gt;
&lt;P&gt;Roman&lt;/P&gt;</description>
    <pubDate>Fri, 07 Jun 2013 17:05:12 GMT</pubDate>
    <dc:creator>Roman_D_Intel</dc:creator>
    <dc:date>2013-06-07T17:05:12Z</dc:date>
    <item>
      <title>Recommendations for Intel(r) Transactional Synchronization Extensions have been published</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981697#M5732</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;Chapter 12 of the most recent (June 2013) "&lt;A href="https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf"&gt;Intel 64 and IA-32 Architectures&amp;nbsp;Optimization Reference Manual&lt;/A&gt;" contains enabling and tuning&amp;nbsp;recommendations for Intel(r) Transactional Synchronization Extensions in the 4th generation Intel(r) Core(tm) processor family.&lt;/P&gt;
&lt;P&gt;Best regards,&lt;/P&gt;
&lt;P&gt;Roman&lt;/P&gt;</description>
      <pubDate>Wed, 05 Jun 2013 09:29:52 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981697#M5732</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-05T09:29:52Z</dc:date>
    </item>
    <item>
      <title>&gt;&gt;Chapter 12 of the most</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981698#M5733</link>
      <description>&amp;gt;&amp;gt;Chapter 12 of &lt;STRONG&gt;the most recent (June 2013)&lt;/STRONG&gt; "Intel 64 and IA-32 Architectures Optimization Reference Manual" contains
&amp;gt;&amp;gt;enabling and tuning recommendations for Intel(r) Transactional Synchronization Extensions in the 4th generation
&amp;gt;&amp;gt;Intel(r) Core(tm) processor family.

Thanks for the information, Roman!</description>
      <pubDate>Thu, 06 Jun 2013 05:21:59 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981698#M5733</guid>
      <dc:creator>SergeyKostrov</dc:creator>
      <dc:date>2013-06-06T05:21:59Z</dc:date>
    </item>
    <item>
      <title>Sergey,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981699#M5734</link>
      <description>&lt;P&gt;Sergey,&lt;/P&gt;
&lt;P&gt;you are welcome! Maybe you find this list of Intel TSX-related resources useful:&amp;nbsp;&lt;A href="http://www.intel.com/software/tsx"&gt;http://www.intel.com/software/tsx&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;Roman&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 09:41:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981699#M5734</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-07T09:41:00Z</dc:date>
    </item>
    <item>
      <title>Roman,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981700#M5735</link>
      <description>&lt;P&gt;Roman,&lt;/P&gt;
&lt;P&gt;I wish to present a simplified example and ask would the following code properly function using RTM?&lt;/P&gt;
&lt;P&gt;Assume you have a ring buffer of size size, fill index fill, empty index empty.&lt;BR /&gt;Assume size of buffer is at least 1 larger than number of entries that can be placed into the buffer.&lt;BR /&gt;Assume you wish to assure a push(x) appears atommicly to insert data and advance the fill index.&lt;BR /&gt;Assume you wish to assure a pop() appears atommicly to extract data and advance the&amp;nbsp;empty index.&lt;/P&gt;
&lt;P&gt;[cpp]&lt;BR /&gt;void* buffer[size];&lt;BR /&gt;__declspec( align( CACHE_LINE_SIZE) ) volatile size_t fill = 0;&lt;BR /&gt;__declspec( align( CACHE_LINE_SIZE) ) volatile size_t empty = 0;&lt;/P&gt;
&lt;P&gt;void push(void* p) {&lt;BR /&gt;&amp;nbsp; while(true) {&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; if(_xbegin() == _XBEGIN_STARTED) {&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; buffer[fill++ % size] = p;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; _xend(); // commit&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; // here when (_xbegin() != _XBEGIN_STARTED)&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; _mm_pause(); // N.B. design assures # pointers .lt. buffer size&lt;BR /&gt;&amp;nbsp; } //&amp;nbsp; while(true)&lt;BR /&gt;} // void push(p)&lt;/P&gt;
&lt;P&gt;void* pop() {&lt;BR /&gt;&amp;nbsp; while(true) {&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; if(_xbegin() == _XBEGIN_STARTED) {&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; if(empty != fill) {&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; void* p = buffer[empty++ % size]; // get data&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; _xend(); // commit&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; return p;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; } if(_xbegin() == _XBEGIN_STARTED)&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; // here when (empty == fill), iow empty buffer&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; _xend(); // commit (release the _xbegin doing no transaction)&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; }&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; // here when (_xbegin() != _XBEGIN_STARTED), or empty buffer&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; _mm_pause(); // N.B. design assures # pointers .le. buffer size&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; // or use sched_yield(), sleep(0), etc...&lt;BR /&gt;&amp;nbsp; } //&amp;nbsp; while(true)&lt;BR /&gt;} // void* pop()&lt;BR /&gt;[/cpp]&lt;/P&gt;
&lt;P&gt;Notes:&lt;/P&gt;
&lt;P&gt;When the fill and empty pointers are cache aligned (in seperated cache lines), then push(p) cannot be aborted by pop() or push(p)&amp;nbsp;issued concurrently by other thread. Presumably the hardware is sophistcated enough for when multiple concurrent push(p)'s are in progress that one thread will always succeed (provided no other activity messes with referenced cache lines).&amp;nbsp;pop() could be aborted by concurrent push(p), and concurrent pop()'s without concurrent push(p) would always have one winner (provided no other activity messes with referenced cache lines).&lt;/P&gt;
&lt;P&gt;When the fill and empty pointers are not cache aligned and in same cache line, then concurrent push(p)&amp;nbsp;and pop() could abort either the push or pop, but at least one would not abort&amp;nbsp;(provided no other activity messes with referenced cache lines).&lt;/P&gt;
&lt;P&gt;Note, "messes with referenced cache lines" includes the cache line written to by "buffer[fill++] = p;" in push(p).&lt;/P&gt;
&lt;P&gt;Are my notes correct?&lt;/P&gt;
&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 14:47:29 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981700#M5735</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2013-06-07T14:47:29Z</dc:date>
    </item>
    <item>
      <title>Follow-up question relating</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981701#M5736</link>
      <description>&lt;P&gt;Follow-up question relating to pop() in above example:&lt;/P&gt;
&lt;P&gt;As written, when the ring buffer is empty, the pop() is performing _xbegin() and _xend() but (when buffer empty) does not modify memory. Will this _xbegin()/_xend() disrupt the _xbegin() of a concurrent push(p) that is secondary to issue the _xbegin()?&lt;/P&gt;
&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 14:54:47 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981701#M5736</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2013-06-07T14:54:47Z</dc:date>
    </item>
    <item>
      <title>Hi Jim,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981702#M5737</link>
      <description>&lt;P&gt;Hi Jim,&lt;/P&gt;
&lt;P&gt;in general RTM does not guarantee that any particular transaction will always succeed (also if retried for many times). For example if there is a page fault on the first access to your buffer -&amp;gt; transaction aborted. Retries do not help because they hit the same issue. Therefore you always need a non-transactional fall-back path (a lock for example):&amp;nbsp;&lt;A href="http://software.intel.com/en-us/blogs/2012/11/06/exploring-intel-transactional-synchronization-extensions-with-intel-software"&gt;http://software.intel.com/en-us/blogs/2012/11/06/exploring-intel-transactional-synchronization-extensions-with-intel-software&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;PS: is line 22 correct? "}&amp;nbsp;if(_xbegin() == _XBEGIN_STARTED)" It seens that xbegins do not match with xends.&lt;/P&gt;
&lt;P&gt;Roman&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 17:05:12 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981702#M5737</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-07T17:05:12Z</dc:date>
    </item>
    <item>
      <title>&lt;blockquote&gt;</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981703#M5738</link>
      <description>&lt;P&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Follow-up question relating to pop() in above example:&lt;/P&gt;
&lt;P&gt;As written, when the ring buffer is empty, the pop() is performing _xbegin() and _xend() but (when buffer empty) does not modify memory. Will this _xbegin()/_xend() disrupt the _xbegin() of a concurrent push(p) that is secondary to issue the _xbegin()?&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;/P&gt;
&lt;P&gt;It may abort because the fill variable belongs both to the write set of the push transaction and to the read set of the pop transaction.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 18:19:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981703#M5738</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-07T18:19:00Z</dc:date>
    </item>
    <item>
      <title>[block]</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981704#M5739</link>
      <description>&lt;P&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;/P&gt;
&lt;P&gt;When the fill and empty pointers are cache aligned (in seperated cache lines), then push(p) cannot be aborted by pop() or push(p)&amp;nbsp;issued concurrently by other thread.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;/P&gt;
&lt;P&gt;push can be aborted by pop because at least of the conflict on the fill variable (write-read).&lt;/P&gt;
&lt;P&gt;push may have at least a write-write conflict with a different push on the fill variable.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 18:42:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981704#M5739</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-07T18:42:00Z</dc:date>
    </item>
    <item>
      <title>The "//" seemed to get</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981705#M5740</link>
      <description>&lt;P&gt;The "//" seemed to get clobbered after the } on line 22 (made comment into statement)&lt;/P&gt;
&lt;P&gt;Good point about page fault, revised code then should have the while(true) loop touch the locations such that the lines are paged in if necessary (small probability they could get paged out between touch and _xbegin())&lt;/P&gt;
&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Fri, 07 Jun 2013 21:15:20 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981705#M5740</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2013-06-07T21:15:20Z</dc:date>
    </item>
    <item>
      <title>Hi Roman,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981706#M5741</link>
      <description>Hi Roman,

&amp;gt;&amp;gt;Chapter 12 of the most recent (June 2013) "Intel 64 and IA-32 Architectures Optimization Reference Manual" contains
&amp;gt;&amp;gt;enabling and tuning recommendations for Intel(r) Transactional Synchronization Extensions in the 4th generation
&amp;gt;&amp;gt;Intel(r) Core(tm) processor family...

I've looked at it and there are about &lt;STRONG&gt;8&lt;/STRONG&gt; pages in total. My question is: Are there some code examples related to Intel &lt;STRONG&gt;TSX&lt;/STRONG&gt; technology?

Thanks in advance.</description>
      <pubDate>Thu, 20 Jun 2013 14:09:48 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981706#M5741</guid>
      <dc:creator>SergeyKostrov</dc:creator>
      <dc:date>2013-06-20T14:09:48Z</dc:date>
    </item>
    <item>
      <title>Hi Sergey,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981707#M5742</link>
      <description>&lt;P&gt;Hi Sergey,&lt;/P&gt;
&lt;P&gt;I counted 28 pages in Chapter 12 :-) . Section 12.3 has code examples for lock elision with Intel TSX&lt;/P&gt;
&lt;P&gt;For further information you can look into &lt;A href="http://www.intel.com/software/tsx"&gt;www.intel.com/software/tsx&lt;/A&gt; (subscribe for page updates)&lt;/P&gt;
&lt;P&gt;Best regards,&lt;/P&gt;
&lt;P&gt;Roman&lt;/P&gt;</description>
      <pubDate>Tue, 25 Jun 2013 10:09:15 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981707#M5742</guid>
      <dc:creator>Roman_D_Intel</dc:creator>
      <dc:date>2013-06-25T10:09:15Z</dc:date>
    </item>
    <item>
      <title>Hi Roman,</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981708#M5743</link>
      <description>Hi Roman,

&amp;gt;&amp;gt;I counted 28 pages in Chapter 12 :-) . Section 12.3 has code examples for lock elision with Intel TSX
&amp;gt;&amp;gt;
&amp;gt;&amp;gt;For further information you can look into &lt;A href="https://community.intel.com/www.intel.com/software/tsx" target="_blank"&gt;www.intel.com/software/tsx&lt;/A&gt; (subscribe for page updates)

Thanks and it looks like I missed something. I'll review what version Intel SDM I was using ( possibly a different one ).</description>
      <pubDate>Tue, 25 Jun 2013 13:07:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Recommendations-for-Intel-r-Transactional-Synchronization/m-p/981708#M5743</guid>
      <dc:creator>SergeyKostrov</dc:creator>
      <dc:date>2013-06-25T13:07:00Z</dc:date>
    </item>
  </channel>
</rss>

