QSharedMemory & QSystemSemaphore

Published Friday August 10th, 2007
8 Comments on QSharedMemory & QSystemSemaphore
Posted in KDE, Qt

One of Qt’s solutions is a class called QtSharedMemory. It lets you share and lock memory between two processes on the same system. Originally written for Qt3 and then ported to Qt4 I set aside some time and created the successors of this class which will be part of Qt 4.4. The locking capability found in QtSharedMemory is useful for cases other then just shared memory and it was taken out and made into its own class. A better API and a nice example the code is in 4.4 and can be seen in the snapshots today.

Here is a “Hello world” shared memory example.
First process A would do the following:

QSharedMemory sharedMemory("foobar");
char *to = (char*)sharedMemory.data();
char *text = "hello world";
memcpy(to, text, strlen(text)+1);

And then until process A destroyed its sharedMemory variable process B can access the “hello world” data.

QSharedMemory sharedMemory("foobar");
char *to = (char*)sharedMemory.data();
qDebug() << to;

QSharedMemory uses the second new class, QSystemSemaphore to provide system wide locking. This is useful when you have different processes accessing the same data. If you are using threads you should use QSemaphore which is much lighter and has more capabilities. Check out the shared memory example documentation which walks through more detailed usage of shared memory.

Due to the different ways that every platform implement these features there are a few exceptions to be away of and they are documented in the class description (for example on HP-UX only one attach to a shared memory segment is allowed per process). QtSharedMemory and QSharedMemory and incompatible to prevent accidentally using them together and it is advisable to stick with one or the other.

The API for these classes has gone through a number of revisions. Check out the class API’s and example and let us know what you think.

Documentation links:
SharedMemory Example

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in KDE, Qt


Giovanni Bajo says:

Is it me, or there’s a bug in your example code you posted? You’re not copying the string terminator πŸ™‚

Craig Scott says:

Very handy, although the QSystemSemaphore class needs an available() member function analogous to the one in QSemaphore. The current QSystemSemaphore API does not provide any way to tell if a system semaphore will block. Sometimes you just want to know if you *could* acquire a resource without actually having to do so.

Carina Denkmann says:

I would like to know if this also supports shared QPixmap’s, system “global” icon or style caches come to mind.
I understand that it would be possible to convert to QImage and store that raw data, but the conversion from/to
QPixmap would be slow.

Unfortunettly we can’t add an available() function because on windows there is no way to determine the value to return.

Either way you never want to write the following code:

if (s.available() > 0)

Craig Scott says:

The QSingleApplication QtSolution could be more reliably implemented using QSystemSemaphore if a QSystemSemaphore::available() member function existed. If available() returned true, no other instance of the application is running, but if it returns false then you know some other instance already has the semaphore. This would be independent of the user running the application (a current weakness of QSingleApplication, as I understand it). But since Windows can’t support it, I guess I’ll just keep waiting for a better solution. πŸ˜‰

Craig Scott says:

Alternatively, can acquire() be made to timeout instead of block indefinitely? If it can be made to timeout with a short period, that would be just as suitable as having an available() function for the use case I just mentioned above.

Commenting closed.

Get started today with Qt Download now