Find the answer to your Linux question:
Results 1 to 6 of 6
If you mmap a file into the core of several processes with MAP_SHARED, does anyone know if writes by one process are atomically updated to the other processes? I guess ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578

    Shared mmap'ings and msync


    If you mmap a file into the core of several processes with MAP_SHARED, does anyone know if writes by one process are atomically updated to the other processes? I guess that they should be, considering that all processes should share the same mem pages, but I can't see the purpose of the MS_INVALIDATE flag to msync in that case.
    Has anyone experimented with this (or knows the specification), or will I have to find out the hard way?

  2. #2
    Linux Enthusiast
    Join Date
    Jun 2002
    Location
    San Antonio
    Posts
    621
    let's look at it logically, we all know how shared memory works, don't we??
    First off:
    Code:
    MAP_SHARED Share this mapping with all other processes  that  map  this
                      object.   Storing  to the region is equivalent to writing to
                      the file.  The  file  may  not  actually  be  updated  until
                      msync(2) or munmap(2) are called.
    this implies that it caches a copy, and doesn't update until sync is called. Yes it may use a write-through technique that will update all the other segments using this, but, hey, it might not. I think this is an implimentation issue, so if you rely on it to work one way you will get hosed when put on (say) a Sun system that might not use the same cache-update resolution technique.
    MS_INVALIDATE just looks like a way to get it to do exactly what you want, when you want. You change the data, you msync it with an MS_INVALIDATE, and it passes the invalidate flag to the other processes using that data. This messes things up in a SMP system, as now it might have done processing using this (now invalid) data. If that is the case it might be a better idea to use a mutex for shared data access. This is how I see it though, Josh, do you remember much from CS470/CS450??
    I respectfully decline the invitation to join your delusion.

  3. #3
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    My idea is that MAP_SHARED maps the same pages into all processing mapping the same file the same way. In that case, there's not much chance that the same memory wouldn't display the same things in all processes that use it. I was also thinking that it might be implementation specific, but I can't think of a single reason why any given kernel wouldn't map the same pages. The purpose of msync in itself seems to be to just sync the memory back to disk, and hence MS_INVALIDATE should somehow be related to that functionality, don't you think? Doesn't anyone have a copy of the IEEE POSIX specs?

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Something just hit me. Do you think it could be that MS_INVALIDATE invalidates all other mappings even though they might not be mapped from the same file offset? (Ie. if one process maps the first page from the start of the file, but another maps the first page from say 10 bytes into the file)

  6. #5
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    OK, never mind. The SunOS man page was much more clear:
    If flags is MS_INVALIDATE, the function synchronizes the
    contents of the memory region to match the current file con-
    tents.

  7. #6
    Linux Enthusiast
    Join Date
    Jun 2002
    Location
    San Antonio
    Posts
    621
    ohhh, that makes much more sense that way. Not so much a message to other processes, but to yourself to say "hey, this is old, get a new copy".
    I respectfully decline the invitation to join your delusion.

Posting Permissions

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