On Tue 28 Apr 2015 at 16:44:53 -0700, Mark Pizzolato - Info Comm wrote: > > Are you suggesting that the memory reference semantics (and coherency > concerns) when using a mmap'ed shared memory area (between two or more > processes) is NOT equivalent to multiple threads in the same process > referencing the same data in their single address space?
One would hope that it IS equivalent. But I've been searching for guarantees that it is and so far I haven't been able to actually find any! I suspect that the authors of the text I've seen deemed it too obvious to spell out, but I'm too careful to want to rely on that theory. I started out with manual pages, but of course the text of a relevant Standard would be better. So I looked at http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html which is hopefully a good place to start. On the positive side, it says this: MAP_SHARED and MAP_PRIVATE describe the disposition of write references to the memory object. If MAP_SHARED is specified, write references shall change the underlying object. However it does /not/ say that this shall happen /immediately/ or somesuch. The remainder of the page remains silent on the topic. Nothing forbids a perverse implementation to copy stuff over only every now and then, by my reading. This thought isn't so far-fetched, since this is exactly what happens to the contents of the file: you need to call msync(2) to update the file. Maybe I'm too paranoid though, but in the past I've been reading comp.std.c and the language-lawyering that goes on in there, and that makes one very careful not to rely on a promise that isn't clearly spelled out. On the positive side, files as opened with shm_open() are called "shared memory objects" and are not deemed to be files (you can only use ftruncate(2) and mmap(2) on them). So even if still no promises are made here, any limitations that are related to mmapping files would not apply. I wonder where an authoritative answer can be found that is actually spelled out. > Aside from my above question, thanks for the fix for the X11R7 issue > with the makefile. > > Meanwhile, Cory's original simh building problem has been fixed in the > github master branch. Great! > - Mark -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl -- 'this bath is too hot.'
pgpz9csmNM8ns.pgp
Description: PGP signature
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh