I am trying to create a function that works around concurrency issues that are documented, and that we are seeing, when doing simultaneous “create table” statements and bulk insert statements (or selects) off of other tables.

To do this, I am implementing a function that uses a boost::shared_mutex that we call around transactions.

We are using a custom version of the boost library, so it is installed in a non-standard place: /usr/local/boost-1.54.0 for development, and /opt/xxx/ for production.

From the documentation, it appears that I can use #pragma LDFLAGS and CFLAGS to point to the non-standard directories.  It appears to honor the CFLAGS option, but not the LDFLAGS option.  If I use the standard /usr/lib64 libraries, calling my function works (but with the wrong library).  Adding the #pragma in, I get the following link error:

Failed to open shared library: libboost_thread.so.1.54.0: cannot open shared object file: No such file or directory.

If I modify LD_LIBRARY_PATH before starting MonetDB, the problem goes away.  Ideally, we don’t want to have to add all of our relevant directories into the environment, but would expect the #pragma to work.

Here is the function definition:

CREATE FUNCTION rwlocker(input INT)

RETURNS INT

LANGUAGE CPP {

#pragma LDFLAGS -L/usr/local/boost-1.54.0/lib -lboost_thread

#pragma CFLAGS -I/opt/tc3/include -I/usr/local/boost-1.54.0/include

#include <boost/thread/shared_mutex.hpp>

    // use lock() for schema changes, lock_shared() for inserts and queries

    static boost::shared_mutex readerWriterMutex;

    result->initialize(result, 1);

    int val = input.data[0];

    switch(val) {

        case 1: // shared lock

            readerWriterMutex.lock_shared();

            break;

       case 2: // shared unlock

            readerWriterMutex.unlock_shared();

            break;

        case 3: // unique lock

            readerWriterMutex.lock();

            break;

        case 4: // unique unlock

            readerWriterMutex.unlock();

            break;

        default: // Error

            break;

    }

    result->data[0] = val;

};

Invocation is easiest with: select rwlocker(12); which will just output a 12, bypassing the reader/writer locking.

Any thoughts on why #pragma LDFLAGS doesn’t appear to work right?

We are using 11.33.3 on CentOS 7.3.1611

Thanks,

Dave