From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Problem Creating File Mapping Object in Memory Mapped FIles
Solved!
The example works on my computer. However this library is specifically only 32 bit programmed and would require some work to make it work in 64 bit LabVIEW.
As to TCP/IP being slow when communicating through localhost, I'm not sure you will see huge improvements through memory mapping. Because when operating between localhost endpoints the Winsock library actually uses internally memory mapping too. But of course it needs to do some synchronizing between the two sides so that the read side doesn't try to read while the write side is updating the memory.
And you will have to do something like that too somehow. So while memory mapping may seem like the golden egg for fast sharing of contents between processes, some of the performance will be eaten away by the necessary synchronization through mutexes or similar in order to guarantee consistent memory states on both sides.
This is my 64 bit safe version of the above library. I chose to implement the thing a little differently with VIs wrapping the individual Call Library Nodes properly.
It is not really what I would call a production ripe implementations with things like the handles and the mapped pointers all being simple 64 bit integers. While they can be connected to each other, doing so will surely result in VERY BAD THINGS happening. So tread lightly when using this version, wear your safety belts and safety googles and think carefully before you hit the run button with any program you used these functions in.
The proper way to implement this would be as LabVIEW classes, wrapping the memory map handle and the actual memory pointer into individual classes, so they CAN"T be wired together accidentally.
