Create or modify the existing mutex & locks to work with and without std::mutex and std::lock_guard

[Kurt Schwehr]

Rather than have #if HAVE_CXX11 in the code, it would be good to be able to have something that can do things like

std::lock_guard<std::mutex> oLock(oDeleteMutex);

without having to do all these #if HAVE_CXX11 conditionals, which is seriously ugly.

#if HAVE_CXX11
static std::mutex oDeleteMutex;
#else
static CPLMutex* hMutex = NULL;
#endif  // HAVE_CXX11

...

#if HAVE_CXX11
    std::lock_guard<std::mutex> oLock(oDeleteMutex);
#else
    CPLMutexHolder oHolder( &hMutex);
#endif  // HAVE_CXX11

...

#if !HAVE_CXX11
    // >= C++11 uses a lock_guard that does not need cleanup.
    if( hMutex == NULL )
        return;

    CPLDestroyMutex(hMutex);
    hMutex = NULL;
#endif

I'm putting in a couple of these so that people can get experience with std::lock_guard.

[Even Rouault]

Thinking that we could likely emulate a std::mutex with the following code (untested), and extend CPLMutexHolder to deal with it, no ? CPLCreateMutex() doesn't go through the global hCOAMutex mutex, so it can be used at any time.

class CPLMutexObject
{
   public:
        CPLMutexObject(int options = CPL_MUTEX_RECURSIVE ) { mhMutex = CPLCreateMutexEx( options ); CPLReleaseMutex(mhMutex); }
       ~CPLMutexObject() { CPLDestroyMutex(mhMutex); }
   private:
        friend class CPLMutexHolder;
        CPLMutex* mhMutex;
};

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.