CODEWITHSUNDEEP
c++ipcboost-interprocess
Janusz Syf
Janusz Syf

Reputation: 393

Ways of identifying the state of opened shared memory

I'm figuring out how to use boost::interprocess, I'm dealing with an application where my processes can be started in more or less unpredictable order and I don't know of a way to tell them which one was the first. They are started on demand, I can't think of a good way of doing any cleanup before they start.

I need to know which process is the first one to properly initialize everything at the start. I'm using a named mutex to make sure the first process can initialize everything it needs to before others start working.

In an ideal case, I can check if shared memory objects were created already using the open_only mode, catching the exception and doing the initialization. Nice and easy and it works.

In a less then ideal case, I can mark the memory as discarded (put a field in the shared data structure, or store that information somewhere else), and if a process starts and finds out about the bogus state it will reinitialize everything. Seems like it might work.

The worst case though, is that the application crashed and there's no indication in the shared memory anything is off. Worse yet, there might be locked mutexes left, either in the shared memory or named ones.

How do I deal with a problem like that? How can I tell whether a given process is joining other workers in a functioning application, or the first one in an application that is just starting?

I'm asking for suggestions on how to deal with this problem, how to approach it and directions on where to look for more info.

Thanks.

Upvotes: 1

Views: 738

Answers (1)

darune
darune

Reputation: 10962

I'm dealing with an application where my processes can be started in more or less unpredictable order and I don't know of a way to tell them which one was the first.

Knowing which process is started first, etc. doesn't bring you closer to solving the issue.

Worse yet, there might be locked mutexes left, either in the shared memory or named ones.

The OS handle that part and free any locks held up by the crashee (it might take a little while to do though)

Use a named semaphore

I guess you could use a named semaphore for a case like that - that way I believe it is possible to know how many processes are running/using the memory/what ever resource you choose to model.

How you design or model that semaphore I cannot recall at the top of my head, however the boost interprocess library does include a named semaphore.

Upvotes: 1

Related Questions