RTFC Posted September 27, 2017 Author Share Posted September 27, 2017 @Jos: Thank you. My Contributions and Wrappers Spoiler BitMaskSudokuSolver BuildPartitionTable CodeCrypter CodeScanner DigitalDisplay Eigen4AutoIt FAT Suite HighMem MetaCodeFileLibrary OSgrid Pool RdRand SecondDesktop SimulatedAnnealing Xbase I/O Link to comment Share on other sites More sharing options...
RTFC Posted September 29, 2017 Author Share Posted September 29, 2017 (edited) As promised, I've updated the bundle (beta v0.91) with a new example script (#3 A and B ) illustrating the simplest way how two processes can read and write to the same shared memory region with HighMem, without mutex negotiation (an example of using mutexes is already provided in my Eigen4AutoIt environment, Test #20). Here's how it works: script A starts up HighMem, pre-allocates some virtual memory (1 GB), defines an allocation, and maps a struct to that allocation, using the absolute address returned by _HighMem_Allocate. (Here we create two allocations, and use the second one for shared I/O.) The struct can be the same size as the allocation or smaller (but not larger!). script A retrieves the allocation's RELATIVE offset to its own base pointer, and stores this together with its PID in an .ini file used for communicating with other processes (you could use fancier/faster ways of achieving this with more sophisticated means of IPC, of course). script B starts up HighMem and reads script A's ini file. Script A's shared memory has a predictable, system-wide, PID-specific name. Script B calls _HighMem_MapExternalMemory ( <script A's PID> ) to obtain its own handle to access this region, and receives its own PID-specific Base Offset for this region. This absolute address will (very likely) be completely different from the absolute address used by script A; this is why script A has to parse relative addresses instead of absolute ones. script B then calls _HighMem_AllocateExternal ( $pid, $relativeOffset, $sizeinBytes, "B" ) with script A's PID (so _HighMem knows which base offset to use), returning an absolute offset that script B can use to map its own struct to the same region. Since the mutex associated with this allocation is not used here, both scripts use the system clock to determine when it's okay for them to write to the last byte of the struct. If the least-significant digit (LSD) of @SEC = 0, script A writes 123 to that byte, and if the LSD of @SEQ = 5, script B writes 234 to the same location. Prior to writing, each script reads what the other script last wrote there. To unmap a shared allocation, both scripts can use _HighMem_Release ( <absolute offset> ). In this case, both scripts just shut down gracefully after half a minute, meaning all allocations (and their mutexes, and the preallocation itself) are automatically released. Edited September 29, 2017 by RTFC My Contributions and Wrappers Spoiler BitMaskSudokuSolver BuildPartitionTable CodeCrypter CodeScanner DigitalDisplay Eigen4AutoIt FAT Suite HighMem MetaCodeFileLibrary OSgrid Pool RdRand SecondDesktop SimulatedAnnealing Xbase I/O Link to comment Share on other sites More sharing options...
RTFC Posted May 8, 2022 Author Share Posted May 8, 2022 Bundle updated to beta v0.9.2; one minor bug fix. My Contributions and Wrappers Spoiler BitMaskSudokuSolver BuildPartitionTable CodeCrypter CodeScanner DigitalDisplay Eigen4AutoIt FAT Suite HighMem MetaCodeFileLibrary OSgrid Pool RdRand SecondDesktop SimulatedAnnealing Xbase I/O Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now