CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 19 of 19
  1. #16
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Communication between two programs via registry?

    Quote Originally Posted by Arjay View Post
    Not at all, an MMF can use a system file or a pagefile as its backing 'store'.

    It contains a sample project that uses an MMF between a log writer and log reader - each in different processes.
    I know MMF can work on an actual file and the pagefile.

    My point in #14 was that if you need shared access from 2 processes (as the OP was asking) that needs to be with an MMF backed with an actual file. Unless maybe (not sure if this works for MMF) you're considering the somewhat awkward handle duplication. Which then brings the issue of how to communicate the handle(s) to the other process, so you have a sort of chicken and egg issue with that route.

    Or am I missing some hidden feature in pagefile packed MMF that allows shared access ?

  2. #17
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: Communication between two programs via registry?

    Quote Originally Posted by OReubens View Post
    My point in #14 was that if you need shared access from 2 processes (as the OP was asking) that needs to be with an MMF backed with an actual file.
    No it doesn't. The MMF is the mechanism for sharing the data - it doesn't matter if the MMF is backed by a file or the pagefile (except with a pagefile you don't need to clean up the file).

    Quote Originally Posted by OReubens View Post
    Unless maybe (not sure if this works for MMF) you're considering the somewhat awkward handle duplication. Which then brings the issue of how to communicate the handle(s) to the other process, so you have a sort of chicken and egg issue with that route.

    Or am I missing some hidden feature in pagefile packed MMF that allows shared access ?
    Of course you need to synchronize access - like you do for any resource shared between threads (or processes). Rather than duplicating handles you can use a named mutex for synchronization. I've wrapped the creation into a class and created a couple of named mutexes based off the mmf name. Here's its use:

    Log Sender Code (process 1)
    Code:
    int _tmain( int argc, _TCHAR* argv[] )
    {
      const int TIMEOUT = 5000;
     
      // Create the mmf class instance
      MMFileStructT< LOGITEM >	logItemMmf( _T("{91085AD2-ECC3-4bbe-B81C-DC53E6E3A39F}"), TIMEOUT );
     
      // Create and open the file mapping
      logItemMmf.CreateMap( );
     
      // Send a bunch of log items over to the LogReceiver process
      for( int x = 0; x < 100; x++ )
      {
        CString sMsg;
        sMsg.Format( _T("Log item msg - %d"), x );
     
        { // Locking scope (briefly lock the mmf to set the log data)
    
          // Lock the mmf using RAII
          AutoLockT< MMFileStructT< LOGITEM > > lock( &logItemMmf, TIMEOUT );
     
          // Change the log data
          LPLOGITEM pLogItem = logItemMmf.raw( );
          pLogItem->uDepth = x;
          _tcscpy_s( pLogItem->szMsg, sMsg ); 
     
        } // Mmf unlocked here
     
        // Signal the LogReceiver process and wait for it to retrieve the log data
        ::SignalObjectAndWait( logItemMmf.GetChannelEvent( MMFile::EVENT_CH1 ),
            logItemMmf.GetChannelEvent( MMFile::EVENT_CH2 ),
            TIMEOUT,
            FALSE );
     
        // Reset the CH2 event
        logItemMmf.ResetChannelEvent( MMFile::EVENT_CH2 );
      }
     
      return 0;
    }
    Log Receiver Code (process 2)
    Code:
    int _tmain(int argc, _TCHAR* argv[])
    {
      const int TIMEOUT = 5000;
    
      MMFileStructT< LOGITEM >	logItemMmf( _T("{91085AD2-ECC3-4bbe-B81C-DC53E6E3A39F}"), TIMEOUT );
    
      logItemMmf.CreateMap( );
    
      HANDLE aHandles[] = { logItemMmf.GetChannelEvent( MMFile::EVENT_CH1 ) };
    
      BOOL bContinue = TRUE;
    
      while( bContinue )
      {
        switch( WaitForMultipleObjects( sizeof(aHandles) /sizeof(HANDLE),
            &(aHandles[0]),
            FALSE,
            INFINITE))
        {
        // Channel 1 Event Fired (From LogSender process)
        case WAIT_OBJECT_0:
          {
            // Lock the inter-process mmf mutex using RAII
            AutoLockT< MMFileStructT< LOGITEM > > lock( &logItemMmf, TIMEOUT );
    
            // Access the log item
            LPLOGITEM pLogItem = logItemMmf.raw( );
    
            // Display the message to the console
            _tprintf( _T( "LogItem - depth: %d message: %s\n" ), pLogItem->uDepth, pLogItem->szMsg );
    
            // Exit if we've reach 100 log items
            if( pLogItem->uDepth >= 99 )
            {
              bContinue = FALSE;
            }
          }
    
          // Reset the CH1 event
          logItemMmf.ResetChannelEvent( MMFile::EVENT_CH1 );
    
          // Set the CH2 event
          logItemMmf.SetChannelEvent( MMFile::EVENT_CH2 );
        }
    }
    P.S. Sorry for the lack of white space, for some reason the editor is stripping it out.
    Last edited by Arjay; January 29th, 2014 at 11:36 AM.

  3. #18
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Communication between two programs via registry?

    Quote Originally Posted by Arjay View Post
    No it doesn't. The MMF is the mechanism for sharing the data - it doesn't matter if the MMF is backed by a file or the pagefile (except with a pagefile you don't need to clean up the file).
    Ah, <expletive deleted> !
    I'm not sure how I forgot about the lpName parameter in CreateFileMapping(). Especially considering that's how the internal communication in our database service is done.

    Then again, I rarely do things this particular way.. If I use mapping, it's usually because it's about actually accessing/modifying a file on disk. If I need shared memory access, I tend to do this with a DLL with a shared data segment, usually because in that case, both processes share a bunch of common code as well anyway.

    Of course you need to synchronize access - like you do for any resource shared between threads (or processes). Rather than duplicating handles you can use a named mutex for synchronization. I've wrapped the creation into a class and created a couple of named mutexes based off the mmf name.
    Hmmm... I'm not sure how you matched up the sharing/communicating of the duplicated filemapping handle between both processes with synchronizing access to the MMF...
    I pointed out myself in the posts earlier that shared memory by itself isn't enough and needs synchronisation.




    I did read your article about the mapping with RAII. It's interesting, but I did find this bit "strange"...
    ReaderWriterLock Reader Writer lock class. Allows single writer, multiple readers.
    There might be a reason for this, but I would imagine that logs would have multiple writers (many apps making log entries) and a single reader (the app displaying the log).

  4. #19
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: Communication between two programs via registry?

    Quote Originally Posted by OReubens View Post
    Ah, <expletive deleted> !
    I'm not sure how I forgot about the lpName parameter in CreateFileMapping(). Especially considering that's how the internal communication in our database service is done.

    Then again, I rarely do things this particular way.. If I use mapping, it's usually because it's about actually accessing/modifying a file on disk. If I need shared memory access, I tend to do this with a DLL with a shared data segment, usually because in that case, both processes share a bunch of common code as well anyway.
    Yeah, a shared section in a dll is one way to go providing you are passing fixed data. I don't think it can accommodate variable length data (MMFs can providing you find a way to 'agree' on the size of the memory between processes).

    Quote Originally Posted by OReubens View Post
    Hmmm... I'm not sure how you matched up the sharing/communicating of the duplicated filemapping handle between both processes with synchronizing access to the MMF...
    I pointed out myself in the posts earlier that shared memory by itself isn't enough and needs synchronisation.
    The MMF wrapper classes automatically create a mmf object with a mutex lock object. The class also creates two named events. Both the events and the mutex names are derived from the mmf name. The events can be used by each process to signal the other process that a data change has occurred.


    Quote Originally Posted by OReubens View Post
    I did read your article about the mapping with RAII. It's interesting, but I did find this bit "strange"...

    There might be a reason for this, but I would imagine that logs would have multiple writers (many apps making log entries) and a single reader (the app displaying the log).
    It's a general purpose lock object - I might have mis-used it by using it in the log sample.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured