<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 22, 2021 at 12:57 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><div><div style="font-family:"Trebuchet MS","DIN Pro",sans-serif;font-size:14px"><p style="margin-top:0px">The library is thread safe and its functions can be called from multiple host threads, even with the same <samp>handle</samp>. When multiple threads share the same handle, </p><p style="margin-top:0px"><br></p><p style="margin-top:0px">extreme care needs to be taken when the handle configuration is changed because that change will affect potentially subsequent cuBLAS calls in all threads. </p><p style="margin-top:0px">                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^</p><div><br></div><p style="margin-top:0px">It is even more true for the destruction of the handle. So it is not recommended that multiple thread share the same cuBLAS handle.</p><div><br></div><div style="font-size:18px">From my reading of this there should be absolutely no issue. The handle configuration is never being changed. It should be set in PetscInitialize() and destroyed in PetscFinalize(). Since lazy configuration of cuBLAS is turned off (right?).</div></div></div></div></div></blockquote><div><br></div><div>You had me add to init.c:</div><div><br></div><div><div style="line-height:18px"><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre"><span style="font-weight:bold">#if</span> defined(PETSC_HAVE_THREADSAFETY)</div><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre">  ierr = PetscCUPMInitializeCheck();CHKERRQ(ierr);</div><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre"><span style="font-weight:bold">#endif</span></div><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre"><span style="font-weight:bold"><br></span></div><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre"><span style="font-weight:bold"><br></span></div>because getHandle, which does lazy initialization, was not thread safe. But I think it is now.</div><div style="line-height:18px"><br></div><div style="line-height:18px">I am going to test without it and remove if it's OK (I'm sure it will be)<br><div style="color:rgb(46,46,46);font-family:Menlo,Monaco,"Courier New",monospace;font-size:12px;white-space:pre"><br></div>And I don't know what they mean by "when the handle configuration is changed". It makes sense to me that the handle would not be thread safe. It is an object and it has state. The purpose of making an object, and not have one global object is to make it thread safe...</div></div><div style="line-height:18px"><br></div><div style="line-height:18px">I can see that it is not thread safe. There were clear non-deterministic race conditions and it differed to a random degree from a serial run each time. A vector norm returned 0 sometimes when the first entry != 0.</div><div style="line-height:18px"><br></div><div style="line-height:18px">Mark</div></div></div>