OMP_SET_NUM_THREADS

[jim_dempsey]

Code:

! 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)?

Jim Dempsey

[Henry_G_Intel]

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

[jim_dempsey]

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-

[jim_dempsey]

Will rewrite and post - Damb Reply to Message is hosing me -grrr...

[jim_dempsey]

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

[Henry_G_Intel]

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