mmap'ing the same file

[Alexandru Palade]

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

 

[Ben Bacarisse]

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.

 

[Jorgen Grahn]

Alexandru Palade <[email protected]> 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

 

[Ben Bacarisse]

Alexandru Palade <[email protected]> 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.