[boost] [interprocess] Improved shared_memory lifetime using file locks?

Subject: [boost] [interprocess] Improved shared_memory lifetime using file locks?
From: Sebastian Theophil (stheophil_at_[hidden])
Date: 2016-09-21 11:45:58

Hi,

coming from Windows, the filesystem persistence of basic_managed_shared_memory is giving us headaches. When we have N processes accessing the same shared memory, and one of them crashes, the other N-1 are in an undefined state. That’s the same on Windows and POSIX platforms and is ok for us. On Windows, the problem resolves itself when the other N-1 processes are all closed and then restarted, because Windows deletes the shared memory automatically.

On POSIX systems, I think we can use file locks to make sure that the shared memory is reinitialized by the first process to access it. I’d appreciate any feedback, especially if it points out the problems with this approach:

- basic_managed_shared_memory(boost::interprocess::open_or_create, …) opens the backing file with flags O_CREAT | O_EXLOCK | O_NONBLOCK
- if that succeeds:
        - we are the first
        - (re-) initialize shared memory
        - also a good time to unlink/open the named POSIX semaphore that’s hanging around in an invalid state too!
        - degrade exclusive lock using flock(LOCK_SH)
- else
        - open file with flag O_SHLOCK (open only, and blocking!)
        - when that succeeds, open shared memory

Problems I can see:

- Only works when (advisory) shared and exclusive locking and the degradation of one to the other is supported (at least flock not supported on Windows, e.g.)
- What about other file systems? NFS?
- Somebody could lock all your files.
        (OTOH, sb could also delete all my backing files all the time. My application would run, but not have any shared memory. Might be an advantage that my application does *not* run when the file is locked.)
- What else?

Is this worth implementing in boost.interprocess?

I appreciate any feedback,
Sebastian

PS: I’ve googled previous discussions about shared memory lifetime in boost.interprocess. I don’t claim that my proposal gives the same semantics as Windows shared memory. It doesn’t and it seems impossible to achieve. I’m looking for, erm, usable semantics on POSIX systems. Clearly, everybody has to implement some lifetime tracking. It would be nice if boost.interprocess provided one or more solutions.

--
Dr. Sebastian Theophil | stheophil_at_[hidden]
Senior Software Engineer



We are looking for C++ Developers: https://www.think-cell.com/career




think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany
https://www.think-cell.com | phone [phone] | US phone [phone]

Amtsgericht Berlin-Charlottenburg, HRB 180042
Directors: Dr. Markus Hannebauer, Dr. Arno Schödl