1

I'm trying to generate shared memory in a distributed manner; I also need the solution to be cross-platform. In order to do so, I need to synchronise the initialisation of this shared memory - using a mutex.

This mutex, thus, needs to be shared.

I've taken a look at this question: Interprocess reader/writer lock with Boost

However, it suggests placing the mutex in shared memory, generated by a central process. This is the exact opposite of what I'm wanting to do. If I had this central process (which they've referred to as parent), I could simply initialise the shared memory in there.

There's also this question: Interprocess mutex with pthreads, however, the answer to this is not cross-platform

I'm trying to achieve:

try {
    getMutex(ID); 
    // I was first 
} catch
{ 
    // someone else has mutex 
}

Is this even possible to do?

Tobi Akinyemi
  • 804
  • 1
  • 8
  • 24
  • How cross platform? (there are some really strange platforms out there!) What API are you using to get your shared memory that is cross-platform? Who owns the shared memory, and how is its identity shared? – Yakk - Adam Nevraumont Jun 23 '20 at 23:50
  • @Yakk-AdamNevraumont right now I'm obtain using the boost library, but I don't mind changing if there's a better solution. For compatibility, I think the main 3, Windows, Mac and Linux, will suffice. And, In terms of ownership of the mutex, it's owned by the first to lock onto it. – Tobi Akinyemi Jun 23 '20 at 23:51
  • Please clarify "distributed shared memory". Usually shared memory is in one location so that two or more entities can access it. If the memory is distributed, the entities may not know where it is. Also, having clusters of shared memory among all the memory is a pain for the operating system to manage; most OSes have one area allocated for all of the shared memory. Just think about managing shared memory interwoven with process memory locations. Nasty. – Thomas Matthews Jun 24 '20 at 00:27
  • @ThomasMatthews I'm actually trying to implement a shared, distributed, concurrent, linked list. I'm using a linked list in order to avoid copying of the entire list, when the capacity is reached – Tobi Akinyemi Jun 24 '20 at 00:28
  • So, clarify "distributed linked list". My picture is that the nodes are scattered around memory (maybe even across platforms). This is what "distributed" means to me. Or do you mean that some processes have some nodes in the list and other processes have other nodes. – Thomas Matthews Jun 24 '20 at 00:30
  • I probably will have a main shared block of memory, controlled by the main mutex holder – Tobi Akinyemi Jun 24 '20 at 00:30
  • @ThomasMatthews Yes, both. However, I think most of that is outside the scope of this question. I'm just wanting to start with this shared mutex – Tobi Akinyemi Jun 24 '20 at 00:32
  • Nasty, distributed linked list. This means that process A must follow links in other processes' memory, if that proccess memory is not swapped out to the hard drive. Much better to use a database. Most databases can handle accesses by multiple processes. – Thomas Matthews Jun 24 '20 at 00:33
  • @ThomasMatthews The processes don't own the memory - only update it – Tobi Akinyemi Jun 24 '20 at 00:33
  • Better to keep a process encapsulated and private. Don't invade another process' memory. – Thomas Matthews Jun 24 '20 at 00:34
  • The point is the opposite, to share information... – Tobi Akinyemi Jun 24 '20 at 00:34
  • If the processes don't own the memory then it isn't distributed. – Thomas Matthews Jun 24 '20 at 00:34
  • Everyone owns the memory - that's what I mean by distributed. However, in this scenario, each node is *managed* by only one process. – Tobi Akinyemi Jun 24 '20 at 00:35
  • However you slice things, _some_ process has to initially create the shared memory segnment, and that process can create a mutex along with it. Even if every process creates its own shared memory segment one of them will end up being first, and that one can create the mutex. – Miles Budnek Jun 24 '20 at 00:42
  • @MilesBudnek So you think instead of trying to obtain a mutex, I should try to obtain shared memory? I think this would crash. – Tobi Akinyemi Jun 24 '20 at 00:45
  • Renamed question to: "How can I obtain a global mutex" – Tobi Akinyemi Jun 24 '20 at 00:47
  • I was thinking more like `if (!sharedMemExists()) { createSharedMem(); } openSharedMem();`, but a lot depends on your exact goals and design. Sharing memory (whether between threads or processes) is full of pitfalls and very easy to get wrong. – Miles Budnek Jun 24 '20 at 00:53
  • @MilesBudnek That's not thread-safe. It needs to be atomic – Tobi Akinyemi Jun 24 '20 at 00:54
  • Sure, it was just intended to get the idea across. You have to handle race conditions and such. The point is that the first process to get there creates the shared memory segment along with whatever shared data structures and synchronization devices you need. The alternative would be to have some arbiter/parent process that sets everything up before starting the other processes. – Miles Budnek Jun 24 '20 at 00:57
  • @MilesBudnek The latter is what I'm avoiding (I really can't do it, I don't know the order in which my programs will be started/killed). In regards to your former, using the pre-check isn't thread-safe. Without the pre-check, I think the behaviour is undefined. The shared memory is designed to be instantiated by a "`parent`". It seems the only solution is a system mutex. I've been looking around and there doesn't seem to be a cross-platform implementation of system mutexes, so I may bite the bullet and implement my own abstraction. – Tobi Akinyemi Jun 24 '20 at 01:09

0 Answers0