I have some code with which I'm trying to make a shared memory segment. This segment is managed, on this end, from within a class. The shared segment will be used in a "bulletin board" fashion. That is, this one process will write to it, and many others will read from it. Without further ado:
#include <string>
#include <sys/types.h>
#include <boost/interprocess/managed_shared_memory.hpp>
static const std::string SHM_NAME("SharedMemory");
static const std::string SHM_STATUS("StatusArray");
static const std::string SHM_INFO1("MfgData");
class Manager {
u_int8_t* _status;
char* _info;
boost::interprocess::managed_shared_memory _shm;
Manager()
: _shm(boost::interprocess::create_only, SHM_NAME.c_str(), 1024)
{
// the process goes out to lunch on this first call, it's like a deadlock
status = _shm.construct<u_int8_t>(SHM_STATUS.c_str()) [128] (0); // array 128 bytes, init to 0
info = _shm.construct<char>(SHM_INFO1.c_str()) [256] (0);
}
public:
~Manager() {
_shm.destroy<u_int8_t>(SHM_STATUS.c_str());
_shm.destroy<char>(SHM_INFO1.c_str());
boost::interprocess::managed_shared_memory_object::remove(SHM_NAME.c_str());
}
Manager* Builder() {
// just in case a previous instance was abnormally terminated
boost::interprocess::managed_shared_memory_object::remove(SHM_NAME.c_str());
return new Manager(); // sort of a factory pattern
}
};
The reading that I have done from the boost website on how to do this suggests that there might be a deadlock. In fact, that's why I put the ctor into the private section and made the builder function: so that, during construction, previous instances could be removed. However, this didn't alleviate the problem.
I tried changing the name of the shared memory segment so that it wouldn't be in use, but still, the process hangs when it gets to those lines of code.
I'm using this link (as well as others from the same documentation site) for my model. At this point, I need a second set of eyes and preferably those experienced eyes of boost interprocess and shared memory.
By the way, the program model that I'm using from that link I provided is the "named shared memory" program. What's quite irritating is that I've copied that program onto my Linux system, built and run it with no trouble. What am I missing?
Thanks for the help, Andy
The problem appears to have been related to something not related to boost at this point. I asked the question, and tagged it thusly, because when I first encountered the problem, this is precisely where the hangup was happening. I believe that hangup was due a blocking request of a mutex buried deep within the boost libraries for interprocess communication. I believe the code construct I have, putting the ctor private and calling a factory function, has alleviated that issue.
Thanks to Brian's great suggestion, I was able to see in moments where the problem was. The issue in this case was that when opening the fifo I'd made earlier, the option for non-blocking wasn't or'ed into the flags and the process was blocking waiting for another party to open the same pipe for writing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With