John Collins, Xi Software Ltd

Co-operating processes on a single host often require some means of communication between themselves. It is often much easier and faster to bring data into memory and use in-memory operations to achieve the required objectives than have all applications refer to a database.

Many applications resort to the System V IPC faciliities - shared memory, semaphores and message queues - to achieve these objectives.

This talk will address various ways and the pitfalls of using these facilities in C and C++ (and some efforts in other languages) gleaned over the past 20 years with examples from software written by the author.

We look at some of the drawbacks of these facilities and the system bottlenecks they can create. The kind of problem that can arise is kernel limitations, lack of ability to grow shared memory segments, interation with other applications using the same facilities and fundamental drawbacks in the facilities themselves. The introduction of many of these facilities predate the introduction of threads and many are not thread-safe unless used with extreme care.

We then move on to look at alternative ways of achieving the same ends using memory-mapped files, file locking and Unix domain sockets. Some performance comparisons and other pros and cons between the different communication methods are presented on various systems including Linux.

We conclude by presenting a general-purpose C++ class library and templates to manage alternative implementations using the System V facilities, the alternatives or any desired combination. We present versions of many of the standard C++ heap allocators, containers and iterators to operate using shared memory or memory-mapped files in a thread-safe way independent of the choice of implementation.

Back to schedule

Google IBM O'Reilly mod3

$Id: JCollins.html 555 2006-09-27 14:04:22Z ray $