10

I have a multithreaded server application that needs mutex locks over some shared memory.

The shared memory are basically sTL maps etc.

Much of the time I'm just reading from the map. But, I also need to occasionally add to it.

e.g. typedef std::map MessageMap; MessageMap msgmap; boost:shared_mutex access_;

void ProcessMessage(Message* message)
{
  //  Access message... read some stuff from it  message->...

  UUID id = message->GetSessionID();

  // Need to obtain a lock here. (shared lock? multiple readers)
  // How is that done?
  boost::interprocess::scoped_lock(access_);

  // Do some readonly stuff with msgmap
  MessageMap::iterator it = msgmap.find();
  // 

  // Do some stuff...

  // Ok, after all that I decide that I need to add an entry to the map.
  // how do I upgrade the shared lock that I currently have?
  boost::interprocess::upgradable_lock


  // And then later forcibly release the upgrade lock or upgrade and shared lock if I'm not looking
  // at the map anymore.
  // I like the idea of using scoped lock in case an exception is thrown, I am sure that
  // all locks are released.
}

EDIT: I might be confusing the different lock types.

Whats the difference between shared/upgrade and exclusive. i.e. I don't understand the explanation. It sounds like if you just want to allow lots of readers, a shared access is all you want to obtain. And to write to your shared memory you just need upgrade access. Or do you need exclusive? The explanation in boost is anything but clear.

Is upgrade access obtained because you might write. But shared means you definately won't write is that what it means?

EDIT: Let me explain what I'm wanting to do with a little more clarity. I'm not yet happy with the answers.

Here is the example all over again but with an example of some code that I'm using as well. Just an illustration, not the actual code.

typedef boost::shared_mutex Mutex;
typedef boost::shared_lock<Mutex> ReadLock;
typedef boost::unique_lock<Mutex> WriteLock;
Mutex mutex;
typedef map<int, int> MapType;    // Your map type may vary, just change the typedef
MapType mymap;

void threadoolthread() // There could be 10 of these.
{   
    // Add elements to map here
    int k = 4;   // assume we're searching for keys equal to 4
    int v = 0;   // assume we want the value 0 associated with the key of 4

    ReadLock read(mutex); // Is this correct?
    MapType::iterator lb = mymap.lower_bound(k);
    if(lb != mymap.end() && !(mymap.key_comp()(k, lb->first)))
    {
        // key already exists
    }
    else
    {
        // Acquire an upgrade lock yes?  How do I upgrade the shared lock that I already        have?
        // I think then sounds like I need to upgrade the upgrade lock to exclusive is that correct as well?

        // Assuming I've got the exclusive lock, no other thread in the thread pool will be able to insert.
        // the key does not exist in the map
        // add it to the map
        {
          WriteLock write(mutex, boost::adopt_lock_t());  // Is this also correct?
          mymap.insert(lb, MapType::value_type(k, v));    // Use lb as a hint to insert,
                                                        // so it can avoid another lookup
        }
        // I'm now free to do other things here yes?  what kind of lock do I have here, if any?  does the readlock still exist?
    }
hookenz
  • 36,432
  • 45
  • 177
  • 286

2 Answers2

15

You said that your application is multithreaded, so you should use boost::thread not boost::interprocess.

From the documentation (not tested) you should do it this way:

typedef boost::thread::shared_mutex shared_mutex;
boost::thread::upgrade_lock<shared_mutex> readLock(access_);

// Read access...

boost::thread::upgrade_to_unique_lock<shared_mutex> writeLock(readLock);

// Write access..

Also note that you acquire it while you lock for read access, so someone may delete this node and it's no longer valid when you get to the write section. WRONG, sorry.

EDIT: I think that explanation in boost is clear. Let's try rephrase it to you anyway:

There are three main types of mutex concepts (I don't count TimedLockable since it's not related to your question):

  • Lockable — just a simple, exclusive ownership mutex. If someone lock()s it no-one can lock() it again until the owner unlock()s it. boost::thread::mutex implements this concept. To lock this concept in RAII style use lock_guard or unique_lock for a more complex interface.
  • SharedLockable — is a Lockable with an additional "shared" ownership. You can get the exclusive ownership with lock() or the shared ownership with lock_shared(). If you lock the shared part you cannot upgrade your ownership to exclusive one. You need to unlock_shared() and lock() again which means that somebody else may modify the protected resource between unlock_shared() and lock(). It's useful when you know a priori what kind of access to the resource you will do. shared_mutex implements this concept. Use lock_guard or unique_lock to get the exclusive ownership and shared_lock to get the shared ownership.
  • UpgradeLockable — is SharedLockable which allows you to upgrade from shared ownership to exclusive ownership without unlocking. shared_mutex implements this concept too. You can use the above locks to get exclusive or shared ownership. To get an upgradable shared ownership use upgrade_lock and upgrade it with upgrade_to_unique_lock.
Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
  • Sorry I think maybe i want to use boost::upgrade_lock and boost::upgrade_to_unique_lock. Maybe you can explain the difference between them. See my edited question. – hookenz Oct 09 '10 at 09:55
  • With UpgradeLockable there can be only one thread in that state but several can be in SharedLockable is that correct? so in order for an upgrade lock to become a unique lock all shared locks need to be unlocked correct? – hookenz Oct 10 '10 at 03:23
  • @Matt: "With UpgradeLockable there ..." only one in unique state and many in upgradable or shared. "so in order for an upgrade ..." Yep. – Yakov Galka Oct 18 '10 at 10:18
  • 1
    So essentially, this is **_NOT_** the answer to OP's question. Because an upgradeable lock cannot be obtained (even if it isn't upgraded yet) by more than one thread... – Guy Oct 26 '14 at 15:56
  • Ran into the term "upgrade mutex type" in some documentation and couldn't find an official definition anywhere; thanks for the excellent and clear explanation. – Wildcard Mar 06 '21 at 00:00
5

You don't want boost-interprocess if you're just using a single process. As the library name implies, it's used for Inter-Process Communication (IPC). You most likely want to use the boost-thread mutex and locking concepts.

#include <boost/thread/locks.hpp>  
#include <boost/thread/shared_mutex.hpp>  

int
main()
{
    typedef boost::shared_mutex Mutex;
    typedef boost::shared_lock<Mutex> ReadLock;
    typedef boost::unique_lock<Mutex> WriteLock;
    Mutex mutex;

    {
        // acquire read lock
        ReadLock read( mutex );

        // do something to read resource
    }

    {
        // acquire write lock
        WriteLock write( mutex, boost::adopt_lock_t() );

        // do something to write resource
    }
}

there's a post on the boost mailing list explaining this as well.

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
  • 1
    Edit: thanks Sam. Can you have a look at my example above that I've edited at the bottom of the question. Would that be the correct usage? – hookenz Oct 09 '10 at 23:51
  • 1
    @Matt, in your case since the read lock is unconditionally acquired when entering `threadoolthread`, I think you want to use `boost::upgrade_to_unique_lock` that ybungalobill has [described](http://stackoverflow.com/questions/3896717/example-of-how-to-use-boost-upgradeable-mutexes/3896816#3896816). Though, I have never used `boost::adopt_lock_t()` so I'm not familiar with the behavior, maybe it works. – Sam Miller Oct 10 '10 at 00:17
  • wouldn't using upgrade_to_unique_lock at the beginning of the thread pool function mean that only one thread in the thread pool could run at a time? – hookenz Oct 10 '10 at 00:47
  • @Matt yes, that is correct. Which is why you would not want to do that. Acquire the exclusive lock by upgrading the read lock only at the scope you need it. – Sam Miller Oct 10 '10 at 01:16
  • `boost::adopt_lock_t()` causes the lock to be `assumed locked already`, this is NOT what you want. – unixman83 Dec 18 '10 at 12:46