Global Mapper v25.0

Multi-threading and GetPathProfileLOS()?

jkenneally
jkenneally Global Mapper UserTrusted User
edited September 2010 in SDK
Hi,

We are implementing a DTED based rendering solution using dted data that has been imported into GMG format.

To optimize performance, I have setup a sub thread in the application that accepts requests to load/unload dted tiles. Each pass of the thread runs through a queue of tiles to unload calling GM_CloseLayer(), and then a queue of tiles to load using GM_LoadLayerList().

We had been making calls to GM_GetPathProfileLOS() on the main thread passing NULL for the layer handle in order to check against all loaded layers, but I ran into a crash that seemed to be related to our sub thread unloading layers at the same time as GM_GetPathProfileLOS() was running with the NULL handle param.

My solution to this was to specify a handle in GM_GetPathProfileLOS() that I could be sure was loaded and not queued for unload, and this seems(?) to avoid the thread safety issues. However, I realized after this switch that my LOS line often crosses numerous dted tiles on its way to the 'target point', so I really need the GM_GetPathProfileLOS() call to use multiple loaded tiles when doing its look-up.

So I have a few questions:
1) Can you tell me for sure that it is safe/unsafe to call GM_GetPathProfileLOS() with a NULL handle while calling GM_LoadLayerList/GM_CloseLayer for various tiles on a sub thread?
2) Can you tell me for sure that it is safe/unsafe to call GM_GetPathProfileLOS() with a specific handle that I know is not being unloaded by a sub thread during the call?
3) Is there a way that I can call GetPathProfileLOS() specifying a list of handles that I know are not being unloaded by a sub thread during the call, and would this be safe?

Thanks!

Comments

  • global_mapper
    global_mapper Administrator
    edited September 2010
    There can definitely be some issues with loading and unloading layers when trying to access those layers through GM_GetPathProfileLOS by passing NULL for the layer list to use them all. There isn't currently a GM_GetPathProfileLOS version that takes a list of layers, but this is something I could add rather easily.

    Another option would be just to use critical sections/mutexes to protect your calls in GM_GetPathProfileLOS and GM_CloseLayer to make sure that no layers are closed while the GM_GetPathProfileLOS function is running.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • jkenneally
    jkenneally Global Mapper User Trusted User
    edited September 2010
    Hi Mike,

    Thanks for the quick reply. We thought about changing things to ensure we are only ever in either GM_CloseLayer() OR GM_GetPathProfileLOS() using a mutex as you are suggesting. However, the GM_GetPathProfileLOS() call is being made as part of a render pass on the main thread, and I'm not really sure I can afford to have the call block while waiting for a GM_CloseLayer call to complete. We did some general profiling a while back, and it seems to me that GM_CloseLayer can take time to complete, although I don't have the specific numbers right now to back that claim up.

    Being able to pass a list of handles to GetPathProfileLOS() would be a great solution, provided we can simultaneously unload handles on a sub thread that are not part of that list.
  • global_mapper
    global_mapper Administrator
    edited September 2010
    I have completed adding a new GM_GetPathProfileLOSEx function that takes a list of layers for you to try. I have placed a new SDK build with this change at http://www.globalmapper.com/GlobalMapperSDK_v134_beta.zip for you to try.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • jkenneally
    jkenneally Global Mapper User Trusted User
    edited September 2010
    Great, thanks! I'll need to spend some time re-arranging code to make use of the new call, but I'll let you know how things go.
  • jkenneally
    jkenneally Global Mapper User Trusted User
    edited September 2010
    Hi Mike,

    I finally finished my code changes to use the new GM_GetPathProfileEx, and downloaded the updated SDK for a test run. However, I have encountered a fairly significant issue trying to run and I was hoping you could provide some insight.

    Our application uses both the Global Mapper SDK, and the GDAL libraries separately. Previous to this update we were using GlobalMapperInterface.dll version 1.31.0, which didnt seem to depend on lti_dsdk_dll.dll. I noticed with this new SDK version you are using some of the same dependencies that GDAL has, including lti_dsdk_dll.dll. My issue seems to be coming from dependency conflicts between the latest Global Mapper SDK and the latest GDAL sdk. In particular, they depend on different versions of this lti_dsdk_dll.dll.

    If I try to run with the older version (6.0.7.1407) of "lti_dsdk_dll.dll" that GDAL depends on, I am getting the following error from (I believe )the new Global Mapper SDK at runtime: "The procedure entry point ??4LTIPixel@LizardTech@@QAEAAV01@@Z could not be located in the dynamic link library lti_dsk_dll.dll"

    So I figured just updating to the new lti_dsdk_dll.dll version your sdk provided would satisfy both Global Mapper and GDAL. However, running with the newer version (7.0.0.2181) of lti_dsdk_dll.dll gives the following error (I believe from GDAL): "The procedure entry point ?getHeight@LTIImage@LizardTech@@QBEIXZ" could not be located in the dynamic link library lti_dsk_dll.dll"

    Having not worked directly with the Geo DSDK libraries, I'm assuming the new DLL introduced functions global mapper depends on, while dropping functions that gdal depends on.

    Any thoughts on this, or how it could be worked around? I don't know if it is feasable, but a really simple stop-gap fix for us would be to have a build of the older Global Mapper 1.31.X sdk that doesnt depend on the "lti_dsdk_dll.dll", etc, but has had the GM_GetPathProfileEx() added.

    I've also made a similar post to the LizardTech forums regarding API changes between versions of lti_dsdk_dll.dll in case I have misdiagnosed the problem.

    Thanks!
  • global_mapper
    global_mapper Administrator
    edited September 2010
    Is it possible to just get an update to GDAL that uses the latest lti_dsdk_dll.dll? It seems like that would be the easiest approach. It's been a while since the LizardTech libraries were updated so I would expect someone would have updated GDAL to use the latest release in the meantime.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • jkenneally
    jkenneally Global Mapper User Trusted User
    edited September 2010
    Hi Mike,

    After a little bit of digging/experimenting, I was able to find a set of built GDAL binaries that have been updated to use the new version of lti_dsdk_dll.dll. As far as I can tell the actual FW_Tools binaries have not yet been updated, but I was pointed to this very useful site through the fw_tools mailing list:

    http://vbkto.dyndns.org/sdk/

    That site provides up-to-date core GDAL binaries that seem to be kept very current. Switching over to those binaries seems to have eliminated the lti_dsdk_dll.dll problem! I was then able to update to the latest global mapper sdk, and hook up to the new GM_GetPathProfileLOSEx function.

    So far everything seems to be working great, although it will need some soak testing before I start to relax... :D

    Thanks again for adding the GM_GetPathProfileLOSEx function for us on short notice!