2

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

Community
  • 1
  • 1
Asvaldr
  • 197
  • 3
  • 15
  • Trying some things i've found, still no avail. http://stackoverflow.com/questions/20325146/share-condition-variable-mutex-between-processes-does-mutex-have-to-locked-be The solution here, doesn't work if you run two completely seperate executables. I commented out the fork, run it. I then comment out the father part and and the mutex initialisers and recompile and run the forked son process. Doesn't work. But if you run as is from the same executable, it works..... – Asvaldr Feb 16 '16 at 02:56

1 Answers1

2

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.

dan4thewin
  • 1,134
  • 7
  • 10
  • Thank you for the info, i'm still not sure if this is the way i want to go because i will possibly have many readers and writers to this shared memory so trying to get the same memory alignment as new processes start will be cumbersome if not problematic. – Asvaldr Feb 16 '16 at 03:00
  • I looked into the OTOH pthread and as stated above (in my first comment on my question) it won't work from two separate executables unfortunately for some unknown reason.. – Asvaldr Feb 16 '16 at 20:49
  • Robust shared pthread mutexes do work from separate executables - that's the whole point. They make use of a system call to enable recovery. Have a look at the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_mutex_trylock.c – dan4thewin Feb 16 '16 at 21:00
  • Thanks @dancancode, i've found the mutex work but the pthread_cond_t won't signal accross even when attributes applied like the mutex pthread_condattr_init(&condAttEx); pthread_condattr_setpshared(&condAttEx, PTHREAD_PROCESS_SHARED); pthread_cond_init(condEx, &condAttEx); – Asvaldr Feb 17 '16 at 03:42
  • That's unfortunate. If you want to start a new question, and post some code, maybe we can figure out what's happening. – dan4thewin Feb 17 '16 at 03:51
  • Thanks for the suggestion, i have made a new question here. http://stackoverflow.com/questions/35448835/pthread-condition-variables-not-signalling-even-though-set-to-pthread-process-sh – Asvaldr Feb 17 '16 at 05:46