- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
! Running on system with 4 processors iMaxThreads = OMP_GET_MAX_THREADS() ! runtime environment returns 4 call OMP_SET_NUM_THREADS(iMaxThreads) ! set to 4 threads !$OMP PARALLEL DO PRIVATE(I) SHARED COUNT DO I=1,COUNT CALL FOO2(SOMETHING(I)) CALL FOO3(OTHERTHING(I)) END DO !$OMP END PARALLEL ... SUBROUTINE FOO2(X) call OMP_SET_NUM_THREADS(2) ! set to 2 threads (race window here) !$OMP PARALLEL SECTIONS !$OMP SECTION block1 !$OMP SECTION block2 !$OMP PARALLEL SECTIONS END SUBROUTINE FOO2 SUBROUTINE FOO3(X) call OMP_SET_NUM_THREADS(3) ! set to 3 threads (race window here) !$OMP PARALLEL SECTIONS !$OMP SECTION block1 !$OMP SECTION block2 !$OMP SECTION block3 !$OMP PARALLEL SECTIONS END SUBROUTINE FOO3
Does the call to OMP_SET_NUM_THREADS affect only the thread that issues the call (thread context variable) or are all threads affected (global variable)?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
The OpenMP 2.5 specification isn't clear on this question. In the Intel OpenMP implementation,the call to OMP_SET_NUM_THREADS should only affect the calling thread. In other OpenMP implementations, the calls to OMP_SET_NUM_THREADS inside the first parallel region may createa race condition. Putting anum_threads clause on the parallel directives is probably a better, more portable option.
Henry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Number of threads is not a clause available in Fortran.
Also, what is not known to me at this time is when in the first-level parallel section a team member requests n threads for then next parallel section it enters, if the Windows threads created on the 1st entry into the second level parallel section are persistent after exit of the section (on behalf of the calling thread) and then the same Windows threads are reused as the same sub-team member number thread upon subsequent re-entry into the second level by the samecalling thread. (that is a mouthful). Example
Thread.0/ handle1 - Main program thread
- First PARALLEL level (assume 3 threads)
Thread.0.0 / handle 1 - Same Window handle that entered this section
Thread.0.1 / handle 2 - New Windows handle
Thread.0.2 / handle 3 - New Windows handle
--- each of the above 3 team members (threads) enter next level (assume each requests 2 threads and 2 are available)
Thread.0.0.0 / handle 1-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will rewrite and post - Damb Reply to Message is hosing me -grrr...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Code:
Thread.0 / handle1 - Main program thread - First PARALLEL level (assume 3 threads) Thread.0.0 / handle 1 - Same Window handle that entered this section Thread.0.1 / handle 2 - New Windows handle Thread.0.2 / handle 3 - New Windows handle - Second Parallel level. Each of the above 3 team members (threads) enter 2nd level (assume each requests 2 threads and 2 are available and given) Thread.0.0.0 / handle 1 Team for first thread in level above Thread.0.0.1 / handle 4 Thread.0.1.0 / handle 2 Team for second thread in level above Thread.0.1.1 / handle 5 Thread.0.2.0 / handle 3 Team for third thread in level above Thread.0.2.1 / handle 6 - End Second Parallel level - End First Parallel level Not that the following makes programming sense - Enter different code for new first parallel level (assume 2 threads) Thread.0.0 / handle 1 - Same Window handle that entered this section Thread.0.1 / handle 2 - Reuse of Windows handle (Thread.0.1 / handle 3 not used but Windows handle 3 reserved an not reused below) - Second Parallel level. Each of the above 2 team members (threads) enter 2nd level (assume each requests 3 threads and 3 are available and given) Thread.0.0.0 / handle 1 Team for first thread in level above Thread.0.0.1 / handle 4 Reuse of same Windows handle Thread.0.0.2 / handle 7 New Windows handle for 1st use Thread.0.1.0 / handle 2 Team for second thread in level above Thread.0.1.1 / handle 5 Reuse of same Windows handle Thread.0.1.2 / handle 8 New Windows handle for 1st use - End Second Parallel level - End First Parallel level
As to why this would make a difference know if the Windows (Linux) thread handles, once allocated, remain bound to the nested level and team member number.
1) There is operating system overhead to create and destroy threads.
2) Resources that are thread specific will persists across entries and reentries of level
3) The application can have a one time resource assessment and then set Windows thread Affinity to a particular processor or group of processors.
Jim Dempsey
Message Edited by hagabb on 12-16-2005 12:25 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
According to the OpenMP 2.5 API, the num_threads clause is available in Fortran. The Intel 9.0 Fortran compiler supports OpenMP 2.5 so you should not have any trouble using the num_threads clause on your parallel directives.
The Intel OpenMP implementationuses a thread pool to avoid the overhead of repeatedly creating and destroying threads. Otherwise, putting an OpenMP parallel region inside of a loop, for example, would incur significant system overhead every time the parallel region was entered (thread creation) and exited (thread destruction). The Intel OpenMP implementation simply reuses threads and adds more threads if needed. However, this would make it difficult toassociate Windows HANDLE's with a particular OpenMP thread team.
Henry
Message Edited by hagabb on 12-16-2005 01:02 PM
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page