mmap'ing the same file

Discussion in 'C Programming' started by Alexandru Palade, Jul 29, 2011.

  1. Hey everyone,

    My OS internals knowledge is quite rusty (if I ever had it), so I was
    wondering if anyone can explain a bit the following situation.
    Here[1]'s the code I'm referring to. The input file it's just a binary
    file with integers one after another.

    Questions:
    1) Is there any reason why I shouldn't write that kind of code?
    2) Why does the statement in the for loop actually hits the disk. I
    would expect mmap to be smarter than that and realize that we are
    talking about exactly the same data on disk - I mean, I got it that
    there are two different virtual addresses, but the physical address is
    the same, isn't it?

    Thanks,
    Alex

    [1] http://pastebin.com/mtfkZsU6
     
    Alexandru Palade, Jul 29, 2011
    #1
    1. Advertising

  2. Alexandru Palade <> writes:

    > My OS internals knowledge is quite rusty (if I ever had it), so I was
    > wondering if anyone can explain a bit the following situation.
    > Here[1]'s the code I'm referring to.


    It's short enough to post here. That way it could be commented on
    without having to copy-and-paste.

    > The input file it's just a binary
    > file with integers one after another.
    >
    > Questions:
    > 1) Is there any reason why I shouldn't write that kind of code?


    That's unanswerable! I suspect what you are worried about is something
    relating to different sizes used in the mmap calls. That's off topic
    here. The excellent group comp.unix.programmer is full of experts who
    can help with this, but try to be more specific when you ask there.

    > 2) Why does the statement in the for loop actually hits the disk. I
    > would expect mmap to be smarter than that and realize that we are
    > talking about exactly the same data on disk - I mean, I got it that
    > there are two different virtual addresses, but the physical address is
    > the same, isn't it?


    That's another question for comp.unix.programmer. Again, I think you
    might need to be more specific about what's puzzling you. (In general
    the disk activity relating to mapped files is unspecified so there may
    be nothing to say about this, but the good folks at c.u.p will have the
    details.)

    From the C point of view:

    Both the int * casts can be removed. I'd use size_t for i and I'd use
    1024UL rather than 1024L (that keep the sizes unsigned). It's better to
    write sizeof(int) rather than '4' all over the place. If you need to be
    sure that you are reading and writing 32-bit ints, you should use
    int32_t from stdint.h but I'd still write sizeof(int32_t) as that is
    self-documenting.

    --
    Ben.
     
    Ben Bacarisse, Jul 29, 2011
    #2
    1. Advertising

  3. Alexandru Palade

    Jorgen Grahn Guest

    On Fri, 2011-07-29, Ben Bacarisse wrote:
    > Alexandru Palade <> writes:


    [mmap question]

    > From the C point of view:
    >
    > Both the int * casts can be removed. I'd use size_t for i and I'd use
    > 1024UL rather than 1024L (that keep the sizes unsigned). It's better to
    > write sizeof(int) rather than '4' all over the place. If you need to be
    > sure that you are reading and writing 32-bit ints, you should use
    > int32_t from stdint.h but I'd still write sizeof(int32_t) as that is
    > self-documenting.


    That last statement makes it sound as if sizeof(int32_t) is always 4.
    Just to be pedantic, that's not true on systems where char is e.g. 16
    or 32 bits. (Not sure if mmap() exists on such systems, but ...)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Aug 3, 2011
    #3
  4. Jorgen Grahn <> writes:

    > On Fri, 2011-07-29, Ben Bacarisse wrote:
    >> Alexandru Palade <> writes:

    >
    > [mmap question]
    >
    >> From the C point of view:
    >>
    >> Both the int * casts can be removed. I'd use size_t for i and I'd use
    >> 1024UL rather than 1024L (that keep the sizes unsigned). It's better to
    >> write sizeof(int) rather than '4' all over the place. If you need to be
    >> sure that you are reading and writing 32-bit ints, you should use
    >> int32_t from stdint.h but I'd still write sizeof(int32_t) as that is
    >> self-documenting.

    >
    > That last statement makes it sound as if sizeof(int32_t) is always 4.
    > Just to be pedantic, that's not true on systems where char is e.g. 16
    > or 32 bits. (Not sure if mmap() exists on such systems, but ...)


    I think so. I seem to recall that POSIX requires 8 bit bytes so the OP
    could leave the literal 4s in there even after switching to int32_t.
    You are right though -- I did not intend to imply sizeof(int32_t) is
    generally 4 and one could infer that from what I wrote.

    --
    Ben.
     
    Ben Bacarisse, Aug 3, 2011
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Mays

    windows equiv to mmap()

    Jim Mays, Oct 23, 2003, in forum: C++
    Replies:
    2
    Views:
    869
    Jim Mays
    Oct 23, 2003
  2. Marco Cassiani

    mmap iterator validity

    Marco Cassiani, Mar 24, 2005, in forum: C++
    Replies:
    1
    Views:
    452
    Victor Bazarov
    Mar 24, 2005
  3. junky_fellow

    mmap vs read/write

    junky_fellow, Feb 25, 2004, in forum: C Programming
    Replies:
    3
    Views:
    918
    Derk Gwen
    Feb 25, 2004
  4. Parzival
    Replies:
    1
    Views:
    339
    Jeff Epler
    Nov 8, 2003
  5. Carl Mackey

    mmap -- memory mapped file

    Carl Mackey, Jun 29, 2006, in forum: Python
    Replies:
    1
    Views:
    2,593
    Alex Martelli
    Jun 29, 2006
Loading...

Share This Page