<?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 OpenMP and POSIX threads on Linux* in Intel® Moderncode for Parallel Architectures</title>
    <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/OpenMP-and-POSIX-threads-on-Linux/m-p/988278#M5933</link>
    <description>To what extent is Intel's implementation of OpenMP on Linux* based on Pthreads?  When I look at the code generated by Intel C++ or Fortran with -openmp, I see a lot of __kmpc* calls such as:&lt;BR /&gt;call      __kmpc_fork_call&lt;BR /&gt;&lt;BR /&gt;I know these are implemented in the compiler OpenMP lib:&lt;BR /&gt;/opt/intel/compiler70/ia32/lib/libguide.a&lt;BR /&gt;&lt;BR /&gt;But there is a lot of functionality added by the compiler, over and above what is provided by Pthreads.  For example, the Fork-Join model with parallel region master and slave threads -- there is no such concept in Phreads.  With Pthreads, all threads are peers.&lt;BR /&gt;&lt;BR /&gt;Are the __kmpc* calls implemented on top of Pthreads, or are they essentially a unique, low-level threading API?&lt;BR /&gt;&lt;BR /&gt;thanks,&lt;BR /&gt;patrick</description>
    <pubDate>Mon, 16 Jun 2003 01:48:22 GMT</pubDate>
    <dc:creator>pbkenned1</dc:creator>
    <dc:date>2003-06-16T01:48:22Z</dc:date>
    <item>
      <title>OpenMP and POSIX threads on Linux*</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/OpenMP-and-POSIX-threads-on-Linux/m-p/988278#M5933</link>
      <description>To what extent is Intel's implementation of OpenMP on Linux* based on Pthreads?  When I look at the code generated by Intel C++ or Fortran with -openmp, I see a lot of __kmpc* calls such as:&lt;BR /&gt;call      __kmpc_fork_call&lt;BR /&gt;&lt;BR /&gt;I know these are implemented in the compiler OpenMP lib:&lt;BR /&gt;/opt/intel/compiler70/ia32/lib/libguide.a&lt;BR /&gt;&lt;BR /&gt;But there is a lot of functionality added by the compiler, over and above what is provided by Pthreads.  For example, the Fork-Join model with parallel region master and slave threads -- there is no such concept in Phreads.  With Pthreads, all threads are peers.&lt;BR /&gt;&lt;BR /&gt;Are the __kmpc* calls implemented on top of Pthreads, or are they essentially a unique, low-level threading API?&lt;BR /&gt;&lt;BR /&gt;thanks,&lt;BR /&gt;patrick</description>
      <pubDate>Mon, 16 Jun 2003 01:48:22 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/OpenMP-and-POSIX-threads-on-Linux/m-p/988278#M5933</guid>
      <dc:creator>pbkenned1</dc:creator>
      <dc:date>2003-06-16T01:48:22Z</dc:date>
    </item>
    <item>
      <title>Re: OpenMP and POSIX threads on Linux*</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/OpenMP-and-POSIX-threads-on-Linux/m-p/988279#M5934</link>
      <description>Hi Patrick,&lt;BR /&gt;The Intel OpenMP implementation for Linux is based on Pthreads. In general, the kmpc_* calls wrap Pthreads functions. The compiler turns OpenMP directives into theaded code but it really doesn't add any functionality that isn't available in the Pthreads library.&lt;BR /&gt;&lt;BR /&gt;It's true that with Pthreads all threads are peers. There's no master-worker relationship between threads &lt;I&gt;unless the programmer chooses to code that way&lt;/I&gt;. Thread libraries (e.g., Pthreads) are designed to be flexible and general. OpenMP, which is designed to express data parallelism, is explicitly master-worker.&lt;BR /&gt;&lt;BR /&gt;Henry</description>
      <pubDate>Mon, 16 Jun 2003 20:50:35 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/OpenMP-and-POSIX-threads-on-Linux/m-p/988279#M5934</guid>
      <dc:creator>Henry_G_Intel</dc:creator>
      <dc:date>2003-06-16T20:50:35Z</dc:date>
    </item>
  </channel>
</rss>

