Running Geosoft library functions in parallel using GNU pthreads
Options
MalteIbsvonSeht
Posts: 3 
Hi everyone,
I am trying to run a Geosoft library function (NLFilt_VVU) in a dll using threads (GNU pthreads). The dll is called from a stand-alone application.
Basically it is working. However, many times the returned data is messed up and sometimes the calling application crashes. So there must be a problem with the pointers. I suspect the pGeo-pointer is passed wrongly to the thread-function or it is somehow altered there.
In the attached file I show the code for the function call without threads (which is working fine) and with threads (which is not working).
Thank you for any hints what could go wrong here.
Malte
I am trying to run a Geosoft library function (NLFilt_VVU) in a dll using threads (GNU pthreads). The dll is called from a stand-alone application.
Basically it is working. However, many times the returned data is messed up and sometimes the calling application crashes. So there must be a problem with the pointers. I suspect the pGeo-pointer is passed wrongly to the thread-function or it is somehow altered there.
In the attached file I show the code for the function call without threads (which is working fine) and with threads (which is not working).
Thank you for any hints what could go wrong here.
Malte
0
Comments
-
The short answer is that the GX API functions are not thread-safe. You will need to lock before calling any API functions. Of course, if the performance issue you are addressing is due to NLFilt_VVU, this will not help you much.
GX Developer 9, which should be released by mid-year, is fully 64-bit though still NOT thread-safe. However, a number of functions that are memory-dependent should see a performance improvement.
0 -
Thanks for that information. Now I don't have to dig any longer...
I was reading in the notes about OleAlreadyInitialized_GEO (which I am calling in the calling apllication): "Create_GEO will initialize OLE to MULTITHREAD mode." But now that seems to mean something else.
What a pity that multithreading is not possible. In our applications it would mean a dramatic performance boost.
0 -
We do use threading and other performance improvement techniques inside some particularly performance-sensitive methods. If you have identified particularly slow methods for your applications, let us know which they are and this will give them more weight to be considered for a performance review. Of course, I cannot assure you of a change, but the libraries are being improved all the time and we would like to focus on those parts that have the most impact for users.0
-
Oasis functions are really fast. But of course, processing multiple data sets takes time while the overall cpu load is only 15% or so for a multi core machine.
I guess that threading inside filter or gridding functions is, in most cases, not possible or would not be as effective as processing several independent data sets in parallel with 100% cpu load.0
This discussion has been closed.