Making effective use of shared memory in high-level languages such as C++ is not straightforward, but it is possible to overcome the inherent difficulties. This article describes, and includes sample code for, two C++ design patterns that use shared memory on Linux in interesting ways and open the door for more efficient interprocess communication.
More Effective Use of Shared Memory on Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’d say that shared memory is usually used where no pthreads are available. Anyway – will a pthread_mutex work in a situation, where the shared memory is being accessed by two distinct processes? And if yes is this behaviour Linux-specific or standarized by POSIX?
I’d say that shared memory is usually used where no pthreads are available.
This is a wrong statement. SysV Shared Memory is an IPC (Inter-Process Communication) mechanism. Pthreads can’t work as an IPC mechanism because it requires that all threads belong to the same process (the process in IPC).
For example, SysV shared memory can be used by the X Window System for communications, sharing fonts, sharing bitmaps, and other such things.
There is an optional part of POSIX which allows for multi process shared memory mutexs, but prior to the Linux 2.6 kernel it wasnt supported. The new threading model allowed for such functionality to be implemented.
I have seen quite some possibilities to check for a nullpointer, like:
if (!pointer)
if (pointer != NULL)
if (pointer != 0)
but this is the the first time I saw someone check 0 against the the pointer:
if (0 != pointer)
🙂
It doesn’t matter in this case, but if you want to write:
if (pointer == 0)
but make a mistake and type:
if (pointer = 0)
It will compile without any errors.
if (0 = pointer)
will give an error.
Ah, true, the other style would just give a warning, which can be overlooked.
It’s still the first time I saw it.
That’s because, TMK, NULL is not guaranteed to be zero in the ansi c standard. But there’s a lot of code that does it, and it always seems to be anyway.
NULL is guaranteed to be false though.
He was referring to that particular usage of the commutativity of pointer equality. The C++ standard specifically defines 0 as the null pointer constant. So does the C99 standard IIRC.
From a casual perusal of this article:
1. shmat returns -1 on an error, not NULL so the error handling there is broken.
2. strncpy is successfully used in a broken manner.
3. The sharing of the mutex here is completely broken. Every process has its own instance of Initializer and the mutex belongs to this instance. The shared datastructure is thus not synchronized.
4. Virtual functions are pointlessly used in the singleton. For one the base class contains the nonparameterized factory method for constructing instances of the subclass, which actually depends on the existence of an instance of Initialize to do all of the work of ensuring that an instance is available. There is no clear ‘interface’ and ‘concrete’ classes, and share a pointless vtable.
5. The allocation strategy is baroque and retarded. If you wish to use the factory pattern for providing concrete instances of abstract base classes, you should probably go ahead and really do that. The sloppiness here with constructors/destructors and the usage of virtual is dangerous. Further the way new is overloaded happens to be particularly bad, and the usage here of a limited resource (shared memory segments) is also in bad style. If you insisted on using this style of constructing instances of classes into shared memory segments, and had need of multiple singletons creating a general shared memory allocator and then using that in parameterized factories is the best approach. Doing this correctly you could actually provide trivial (and inefficient) synchronization with a smart pointer that makes use of a semaphore.
6. This code creates a shared memory segment that’s never cleaned up. You’ll have to use ipcrm to get rid of that sucker. If you do anything to change the layout of the class without manually removing the segment you’ll probably find yourself with a lot of segfaults. Which just exposes the extreme brittleness of this approach as demonstrated, even without leaving a junk segment floating around.
7. This is actually not an especially efficient form of IPC, especially not with this example.
P.S. Please, continue using char* for strings in 2005. It hasn’t caused enough harm yet.
Edited 2005-11-14 17:10
It’s example code…. Calm down.
Teaching people how to do things incorrectly does nothing to educate them.