2

I'm trying to understand the implications of using the same System V key_t value for allocating a shared memory buffer via shmget() and a semaphore via semget(). Does this present any conflict, i.e. should I assign a separate key value for the shared memory buffer and the semaphore? Or are the semaphore and the shared memory distinct? Perhaps they are distinct but somehow related? What would happen, in other words, if called both semget(0x1000, 1, IPC_CREAT|0660) and shmget(0x1000, 1, IPC_CREAT|0660)?

I understand that keys are system-wide values. I also understand that ftok() is the standard way of generating key_t values, but this is not under my control.

Context: I wrote some code which is in an advanced state of development that invokes routines that are built using System V IPC shmget/semget. My code uses fixed semaphore IDs (which internally translate to keys) which, it turns out, have the same numerical values as fixed shared memory IDs (which also internally translate to keys) used elsewhere. The immediate question is, whether I need to revise my code to assign a unique ID across both semaphores and shared memory buffers, or keep it as-is (unique just across semaphores); the greater question is this a caveat I need to be aware of for the future. With the current code, there are no errors and testing so far reveals no problems, but that doesn't mean that something can't go wrong.

Vercingatorix
  • 1,838
  • 1
  • 13
  • 22

1 Answers1

0

Considering that they use the same keyspace, it is highly likely that there exists an implementation where semget is implemented on top of shmget or otherwise have interoperability issues with using the same key for both. In that case, if the documentation is reliable, then IPC_CREAT will notice and error one of them out so you can handle the situation.

Also not using ftok() does leave you with greater exposure to collisions with someone who is using ftok(); but then again ftok() is only statistically unique anyway.

Joshua
  • 40,822
  • 8
  • 72
  • 132