Soft MetaTrader 5. It's trading terminal. It's "indicator" windows are little cpp-like programs. They can load pure cpp dlls. Every "indicator" works in separate thread.
I need to create shared memory stuff which can be accessable from every "indicator". Also for shared memory could be loaded in every indicator it must be in particular dll.
I found info about boost interprocesses.
I am newbee with boost and multithreading.
So I wonder am I right way?
Create dll with shared memory functionality and interface to access it from indicator.
Load dll in several "indicators".
Access it from several "indicators" in real-time?
Could you also advice other ways?
Global variables in shared libraries are not shared across the library user processes. That segment of data is created for every process which loads the library, only the read-only code segment is actually shared.
You need to use a library for shared memory, such as boost::interprocess shared_memory_object or POSIX Shared Memory, or Qt's QSharedMemory. That is however in case you need inter-process communication.
There is nothing special you need to do in order for multiple threads to access shared memory in the same process, aside from using a mutex to prevent data races.
Related
Problem (in short):
I'm using POSIX Shared Memory and currently just used POSIX semaphores and i need to control multiple readers, multiple writers. I need help with what variables/methods i can use to control access within the limitations described below.
I've found an approach that I want to implement but i'm unsure of what methodology i can use to implement it when using POSIX Shared memory.
What I've Found
https://stackoverflow.com/a/28140784
This link has the algorithm i'd like to use but i'm unsure how to implement it with shared memory. Do i store the class in shared memory somehow? This is where I need help please.
The reason I'm unsure is a lot of my research, points towards keeping shared memory to primitives only to avoid addressing problems and STL objects can't be used.
NOTE:
For all my multi-threading i'm using C++11 features. This shared memory will be completely seperate program executables using C++11 std::threads from which any thread of any process/executable will want access. I have avoided the Linux pthread for any of my multi-threading and will continue to do so (except if its just control variable not actual pThreads).
Solution Parameters aimed for
Must be shareable between 2+ processes which will be running multiple C++11 std::thread that may wish access. I.e. Multiple Writers (exclusive one at a time) while allowing multiple simultaneous readers when no writer wants access.
Not using BOOST libraries. Ideally native C++11 or built in linux libraries, something that will work without the need to install abstract libraries.
Not using pThread actual threads but could use some object from there that will work with C++11 std::thread.
Ideally can handle a process crash while in operation. E.g. Using POSIX semaphore if a process crashes while it has the semaphore, everyone is screwed. I have seen people using file locks?
Thanks in advance
keeping shared memory to primitives only to avoid addressing problems
You can use pointers in and to shared memory objects across programs, so long as the memory is mmaped to the same address. This is actually a straightforward proposition, especially on 64 bit. See this open source C library I wrote for implementation details: rszshm - resizable pointer-safe shared memory.
Using POSIX semaphore if a process crashes while it has the semaphore, everyone is screwed.
If you want to use OS mediated semaphores, the SysV semaphores have SEM_UNDO, which recovers in this case. OTOH pthread offers robust mutexes that can be embedded and shared in shared memory. This can be used to build more sophisticated mechanisms.
The SysV scheme of providing multiple semaphores in a semaphore set, where a group of actions must all succeed, or the call blocks, permits building sophisticated mechanism too. A read/write lock can be made with a set of three semaphores.
How can I mark data structures that wont be copied on fork?
I have a program that uses fork() and I cannot modify it.
The program loads a shared library that uses threads, and was written in C++.
Since threads are not duplicated on fork, I am afraid that I loose references to some objects that I allocated on of the threads.
How can I avoid that?
Is there an option to mark objects that wont be copied on fork()?
I am writing a library that I load with the application in order to override some of it's function and force it to communicate with a remote server.
The library creates a thread that runs in the background.
The program calls fork().
And I must use boost objects for all threads/shared memory.
Thanks.
I have an array that I need to share between two processes. The first process has an injected DLL that constantly grabs info about a few objects, and the second process needs to receive this information. I constantly update this array (the data in the object changes a lot), and the other process needs to constantly receive these updates. I've seen examples where people use shared memory, but I'm not sure how I could use it to constantly update the array. Any advice or code you can throw at me?
You can use memory mapped file to share your array among several processes.
You can share data in a DLL between processes that load that DLL. See How do I share data in my DLL with an application or with other DLLs? for details on how to use #pragma data_seg to do this. So if you store the array in your DLL and both processes open the DLL, all you need is some sort of synchronisation (e.g. a mutex) to arbitrate shared access to the data.
For convenience you would probably want to implement exported functions in the DLL to read/write the array data rather than exporting the raw array itself.
I am writing a server side application in C/C++ which consists of 1 main daemon and several child processes.
I want the child processes to be extremely lightweight so that they can be spawned/killed without too much overhead (over and above that imposed by the OS).
I am building the main daemon and the children apps to make extensive use of shared libraries. In fact, the main daemon loads up all the shared libraries required by the child applications, and sets up the required (shared) memory structures etc.
My underlying assumption is that since the shared libraries (some of which are huge) are already loaded by the main daemon, the child applications will be able to launch quickly and simply attach to the loaded libraries - without having to load the shared libs, and thus resulting in a slightly fast time to be spawned - is this assumption correct?
[[Added]]
I am working on Ubuntu 10.0.4 LTS
The code segment of your shared libraries will be shared by all processes, no particular restriction w.r.t who loaded/spawned. However, it may take variable time depending upon how many symbols are used in the process, as those will be resolved during load.
But if you are forking, there isn't much to do so it will be fast with respect to launching new binary.
I have an old C++ library which has been designed for use in single-threaded environmens.
The library exposes the interfaces for initialization, which change the internal data structures of the library, and usage, which only reads data and makes calculations.
My objective is to use this library in a Windows multithreaded application, with different threads calling instances of the dll initialized with different data.
Assuming that rewriting the dll to allow multithreading would be prohibitive, is there some way to let multiple instances of a DLL exist in the same process, with separate memory spaces, or to obtain a similar result by other means?
If the DLL contains static resources, then those would be shared among all instances created.
One possible way would be to create a single instance and restrict access to it using some kind of lock mechanism. This may reduce performance depending on usage, but without modifying internal structure of DLL, it may be difficult to work with multiple instance.
The sharing of static resources between all threads attached to a single DLL within a process conspires against you here.
However, there is a trick to achieve this. So long as DLLs have different names, then the system regards them as being different and so separate instances of code and data are created.
The way to achieve this is, for each thread, copy the DLL to a temporary file and load from there with LoadLibrary. You have to use explicit linking (GetProcAddress) rather than lib files but that's really the only way.