Opened 6 years ago

Closed 3 years ago

#6449 closed enhancement (wontfix)

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

Reported by: Kurt Schwehr Owned by: Kurt Schwehr
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: svn-trunk
Severity: normal Keywords:


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;
static CPLMutex* hMutex = NULL;
#endif  // HAVE_CXX11


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


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

    hMutex = NULL;

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

Change History (2)

comment:1 by Even Rouault, 6 years ago

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
        CPLMutexObject(int options = CPL_MUTEX_RECURSIVE ) { mhMutex = CPLCreateMutexEx( options ); CPLReleaseMutex(mhMutex); }
       ~CPLMutexObject() { CPLDestroyMutex(mhMutex); }
        friend class CPLMutexHolder;
        CPLMutex* mhMutex;

comment:2 by Even Rouault, 3 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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 if it is not already reported there.

Note: See TracTickets for help on using tickets.