Click here to Skip to main content
Click here to Skip to main content

Tagged as

Interprocess Communication using Shared Memory

, 13 Dec 1999
Rate this:
Please Sign up or sign in to vote.
A client-server model using shared memory for interprocess communication
  • Download demo project - 10 Kb
  • <!-- Article Starts -->

    This article presents a client/server model where the communication between processes is done using shared memory. Since shared memory may be used only on a single machine, all processes must run on a same computer. This is an obvious limitation. However, the advantage is a speed of communication (note that speed may be severely compromised by a bad implementation on both sides - client and server). Another advantage is that this method is available on any platform (Windows 95/98 as well as Windows NT).

    Using shared memory enables us to design a system where we have a single server and multiple clients communicating in both directions with the server. Communication is initiated by the client -- server is normally in idle state waiting for the client request. Communication is thread safe is a sense that only a single client may exchange information with the server at any moment of time.

    Both client and server must create several global named objects:

    • File mapping object that is mapped to a pointer to application specific structure within each process.
    • Two (2) named events for communication between the server and a single client.
    • Mutex to synchronize excess to the server among multiple clients.
    Synchronization among different clients is explained with the following pseudo code:
    // Client wants to communicate with the server
    if WaitForSingleObject(global named mutex object) is free then
        execute communication session with the server (see below)
        ReleaseMutex(global named mutex object)
    This ensures that only a single client may execute a communication session with the server. While the communication session is active, every other client is waiting for the global named mutex object (of course, only if it needs to communicate with the server at exactly the same moment as any other client). This protection is not needed on the server side (it does not need the global named mutex object) since client request is guarantied to come from a single client at a time.

    Following pseudo code shows how the communication session is performed between the server and a client:

    Client side

    if WaitForSingleObject(global named mutex object) is free then
       Fill application specific structure mapped as a shared memory
       SetEvent(m_hExec)
       if WaitForSingleObject(m_hDone, timeout) is WAIT_OBJECT_0 then
          Handle values in the application specific structure returned from the server
       else
          Timeout waiting for the server
       ReleaseMutex(global named mutex object)
    

    Server side

    if WaitForSingleObject(m_hExec, timeout) is WAIT_OBJECT_0 then
       Get values from the application specific structure
       Set return values
       SetEvent(m_hDone)
    

    The timeout used in a WaitForSingleObject on the client side depends on the task that is done within the server. In order to speed up the communication, server needs to be as fast as possible.

    Timeout used in a WaitForSingleObject on the server side depends on the server side implementation. Sample code (for simplicity) uses a timer handler that periodically checks for client side requests. In a real production code, one should use a separate thread and a WaitForMultipleObjects function that waits for event m_hExec and at the same time for the event that will shutdown the thread (application exit). In this case, timeout may be infinite. This will improve server performance dramatically since it will be able to respond to client request immediatelly (the delay may be only if it is already handling another client request).

    Usually, server is started first and any client started later will connect to the server. Sample project is designed in a way that the first instance is automatically the server and any other instance started later is a client. The communication handles correctly the situation when the server is closed while the clients are running.  What needs the special consideration is the initialization phase when the server and clients are distinct and different applications. In this case, there is a possibility to prevent starting the client if the server is not running or to allow the client to run but to check (and connect) to the server when the client needs to send something to the server. Following pseudo code shows initialization of the client and the server:

    Client side

    m_hMap = OpenFileMapping(...)
    if m_hMap is NULL then
       Server is not running
    else
       pointer to structure = MapViewOfFile(m_hMap, ...)
    

    Server side

    m_hMap = CreateFileMapping(...)
    if GetLastError() is ERROR_ALREADY_EXISTS then
       Server is either started for the second time or previous server instance 
          is killed while the clients are still running.
    pointer to structure = MapViewOfFile(m_hMap, ...)
    

    Multiple instances of the server must be prevented. This can be done using any of the techniques to prevent multiple instances of a single application.

    This design is used in the Runtime Monitoring Agent and performs very good. Multiple clients (from different proceses and threads) are able to communicate with the single server in a very fast and reliable manner.

    License

    This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

    A list of licenses authors might use can be found here

    Share

    About the Author

    Zoran M. Todorovic
    Web Developer SCA d.o.o.
    Serbia Serbia
    I am a cofounder of SCA Software, company that specializes in software for process control, visualization and communication. Programming for the last 10 years in C++, Delphi. Visual C++ for the last 6 years. Degree in Electronics Engineering and Telecommunications.

    Comments and Discussions

     
    BugSEH protection on EXCEPTION_IN_PAGE_ERROR PinpremiumCristian Amarie6-Aug-14 23:06 
    Bug64 bit issue Pinmembers4nCh021-Sep-11 2:59 
    Generalmemory allocation Pinmembercharian092023-Nov-08 18:47 
    Generalshare memory error Pinmemberwillwang31-Mar-08 23:29 
    GeneralRamesh PinmemberMember #374096222-Jan-07 20:21 
    GeneralNo communication under different user context PinmemberAshutosh Bhawasinka18-Jul-06 0:13 
    QuestionSharing an alreay allocated buffer? Pinmembertomerg2216-Nov-05 8:48 
    Questionlibrary mm.h in C for shared memory??? Pinmembermora2629-Oct-05 14:31 
    GeneralThanks PinmemberThe NULL Developer13-Sep-05 3:00 
    QuestionHow to share objects between process PinmemberAsif Khattak16-Jan-04 2:23 
    Generalshared memory limit PinmemberKenneth Suralta12-Jan-04 19:22 
    GeneralRe: shared memory limit Pinmembercristip329-Apr-04 22:13 
    GeneralSharing Pictures using IPC PinmemberMorrowyn26-Nov-03 2:45 
    GeneralNot Completely Robust Pinmemberxxgreg10-Apr-03 3:36 
    GeneralProblem on Windows 2000 Server ... Need Help PinsussAmit Rahul13-Mar-03 13:58 
    GeneralRe: Problem on Windows 2000 Server ... Need Help PinsussAnonymous28-Jul-03 23:23 
    GeneralError... PinmemberStephan Poirier24-Feb-03 17:32 
    GeneralProducer-Consumer-Watcher Problem Pinmembersreemail26-Oct-02 4:08 
    Generalimprovement PinmemberHugo Hallman21-Oct-02 1:18 
    QuestionHow can i share structure data? Pinmemberkrkim9-Apr-02 7:08 
    AnswerRe: How can i share structure data? PinsussAnonymous12-Oct-02 22:32 
    AnswerRe: How can i share structure data? PinmemberHugo Hallman21-Oct-02 1:15 
    Generalinter process communication Pinmemberpriya varshney3-Apr-02 5:02 
    GeneralRe: inter process communication PinsussG. Shankar15-Oct-02 21:17 
    GeneralRe: inter process communication Pinsussprathiba6-Nov-02 18:40 

    General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

    Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

    | Advertise | Privacy | Mobile
    Web02 | 2.8.140814.1 | Last Updated 14 Dec 1999
    Article Copyright 1999 by Zoran M. Todorovic
    Everything else Copyright © CodeProject, 1999-2014
    Terms of Service
    Layout: fixed | fluid