vslloadstreamm FORTRAN thread safe ?

[jasno]

Hi,
I see that the doc says that Vsl is thread safe, but is that tru for ALL the API ? I have
a parallel code in Fortran using OpenMP that uses vslloadstreamm which dies when
OMP_NUM_THREADS is > 1, otherwisae is fine. If I comment out this routine then
OMO_NUM_THREADS can be > 1 (but obviously the output is now broken).

--
jason

[Andrey_N_Intel]

Hi Jason,
Would you be able to provide a test case that demonstrates the issue or, at least, a detailed description of how you use Intel MKL RNGs (including storing/loading random stream descriptive data) in your parallel applicationthatwould help us to reproduce the behavior on our side?
The additional details about OS, mode (IA32 or Intel 64), version of the library and build/link line would be also useful.
Thanks,
Andrey

[jasno]

Hi,
Unfortunately its buried in a lot of code and not easy to extract, but if don't get somewhere with it I'll try and make an example that shows the problem.

I am using ifort and MKL on a RHEL6 OS 64bit. ifort --version returns
"ifort (IFORT) Mainline 20120222"

I am basically using openmp along the lines of

!$OMP PARALLEL IF(N>1000) DEFAULT(NONE) &
!$OMP SHARED(STATE,NLOOP,brng,method,SEED) &
!$OMP PRIVATE(I,THREAD_STATE,start,errcode,stream,tBuf,kind1array) FIRSTPRIVATE(JIN)

thread_state = state

!$OMP BARRIER

start = genStart(thread_state)

! ***** Initialize *****
errcode= vslnewstream( stream, brng, SEED )
If (errcode .NE. VSL_ERROR_OK) Then
call CheckVslError(errcode)
End If

Do i = 1, nloop

! ***** Get State *****
errcode= vslsavestreamm( stream, kind1array )
If (errcode .NE. VSL_ERROR_OK) Then
call CheckVslError(errcode)
End If
!
! Do Stuff
!
! ***** Replace State ****
errcode= vsldeletestream( stream )
If (errcode .NE. VSL_ERROR_OK) Then
call CheckVslError(errcode)
End If
errcode= vslloadstreamm( stream, kind1array )
If (errcode .NE. VSL_ERROR_OK) Then
call CheckVslError(errcode)
End If

errcode= virnguniformbits32( method, stream, myRange, tBuf(start))
If (errcode .NE. VSL_ERROR_OK) Then
Write(0,*) "virnguniformbits32"
call CheckVslError(errcode)
End If

! Use Random Numbers

End Do

!$OMP MASTER

state = thread_state

! ***** Deinitialize *****
errcode= vsldeletestream( stream )
If (errcode .NE. VSL_ERROR_OK) Then
call CheckVslError(errcode)
EndIf

!$OMP END MASTER
!$OMP END PARALLEL

=============================================================

Should that be an allowable usage model ?

[Andrey_N_Intel]

Hi Jason,
Thanks for the code.
This usage model should be allowable, however let me ask the additional clarifying questions:
1. Which basic random number generator (brng) do you use?
2. How do you allocate the memory for the buffer to store random stream data?Doesit have the size sufficient to hold the state of BRNG (I assume you used vslgetstreamsize() functionfor this goal)?
3. Do you use Intel MKL in LP64or ILP64 mode? Which MKL libraries do you link?
4. It's still a bit unclear to me which version of Intel MKL you use. Is it 10.3.x? Or, probably, you use MKL as a part of the Intel Fortran Composer? If this is the case, would you provide the version of the package?
Thanks,
Andrey

[jasno]

Hi Andrey

Its good to know the basic idea is supported, if not my current implementation :-)

I am usingbrng=VSL_BRNG_MT19937

I have used thevslgetstreamsize as you suggest which from memory returns 2520 and I use this

value to allocate memory dynamically. I have also tried statically allocating a larger array (5000)

but still nobetter.

I think I am using ILP64 (slightly uncertain as its all tied up inside a build system), can check if its important.

As to version, you are correct as to it being one from Composer, it is calledcomposerxe_mic.0.029 which I

think might be beta. I'll go to another machine and rebuild it using a standard release version (ifort --version

on the other machine givesifort (IFORT) 12.1.0 20110811 and I think the composer version is

composer_xe_2011_sp1) and see if that helps.

--

jason

[Andrey_N_Intel]

Hi Jason,
This is helpful, thanks. We would try to reproduce thebehavior on our side, and get back to you once we have the update.
Best,
Andrey

[Andrey_N_Intel]

Hi Jason,
We reproduced the crashyou described,and thisissue is unknown to us. It's now investigated.
Thanks,
Andrey