Message Queuing, semaphores, and shared memory for IPC Communications

There are three kinds of IPC we call XSI IPC, i.e. message queue, semaphore, and shared memory. The XSI IPC originates from the IPC function of System V. Because the XSI IPC does not use the file system's namespace, it constructs its own namespace, which is often criticized.

Similarities: The IPC structure in each core is referenced with an identifier of a non-negative integer. For example, to send or cancel a message queue, you only need to know its queue identifier. Unlike file identifiers, the IPC identifier is not a small integer, and when an IPC structure is created and later deleted, the identifier associated with the structure is added 1 consecutively until the maximum positive value of an integer is reached and then back to 0.

Identifiers are the internal names of IPC objects, and an external name scheme is required to enable multiple cooperative processes to converge on the same IPC object. The key is used for this purpose, and each IPC object is associated with a key, so key is used as the external name of the team.

Pros and Cons: The IPC structure works in a system-wide, with no access count. For example, if a process creates a message queue, puts a few messages in the queue, and then terminates, but the message queue and its contents are not deleted, they are remaining in the system until a process calls MSGRCV or Msgctl to read the message or to delete the message queue. Or a process that executes the IPCRM command to delete a message queue, or to delete a message queue by a system that is being restarted, the pipeline is completely deleted when the last access pipeline's process terminates, compared to the pipeline. For FIFO, although the last reference FIFO process terminates when its name remains in the system until it is explicitly deleted, the data left in the FIFO is completely deleted at this time, so it is illusory.
Another problem with XSI IPC is that these IPC structures do not have names in the file system, and we cannot use functions that use file systems to access them or modify their properties. To support them, they had to add more than 10 new system calls (Msgget,semop,shmat). We cannot see the IPC objects with the LS command, cannot delete them with the RM command, and cannot modify their access rights with the chmod command. So they had to add new commands to IPCS and IPCRM.
Because these IPC are not file descriptors, they cannot be used with multiplexed I/O functions: Epoll/select/poll ( This is a fatal injury, because many of the high-performance server programming models are now using Epoll, So the three kinds of communication mechanisms can only be used in some simple occasions ). This makes it difficult to use more than one IPC structure at a time and to use the IPC architecture in file or device I/O. For example, without some form of busy-waiting for loops, you cannot have a server process wait for messages that will be placed in either of the two message queues.
One other advantage of Message Queuing is that it is reliable, the flow is controllable, and the records are processed in a non-FIFO manner.

Related APIs:

Signal Volume:

It is a counter that is used for multi-process access to a shared-memory data object.
#include <sys/sem.h>
int Semget (key_t key,int num_sems,int Sem_flgs);
int semctl (int sem_id,int sem_num,int command ...);
int semop (int sem_id,struct sembuf *sem_ops,size_t num_sem_ops);

Shared Memory:
Allows two or more processes to share a given store, and typically semaphores are used to synchronize access to shared storage
#include <sys/shm.h>
int Shmget (key_t key,size_t size,int shmflag);
void *shmat (int shm_id,const void *shm_addr,int shm_flag);
int shmctl (int shm_id,int cmd,struct shmid_ds *buf);
int SHMDT (const void *SHM_ADDR);

Message Queuing:
Provides a way to send a block of data from one process to another (generally new applications are deprecated)
#include <sys/msg.h>
int Msgget (key_t key,int MSGFLG);
int msgctl (int magid,int cmd,struct msgid_ds *buf);
int msgsnd (int msgid,void *msg_ptr,size_t msg_sz,int msgflag);
int MSGRCV (int msgid,void *msg_ptr,size_t msg_sz,long int msg_type,int msgflag);

Example

Print locations where different types of data are stored

#include <stdio.h> #include <sys/shm.h> #defineARRAY_SIZE40000 #definemalloc_size100000#defineshm_ size100000#defineshm_mode0600/* user Read/write */chararray[array_size];/* uninitialized data = BSS */intmain (void) { Intshmid;char*ptr, *shmptr;printf ("array[" from%p to%p\n ", (void *) &array[0],  (void *) &array[array_size] );p rintf ("Stack Around%p\n", (void *) &shmid), if (ptr = malloc (malloc_size) = = NULL) printf ("malloc error");p rintf ( "Malloced from%p to%p\n", (void *) PTR,  (void *) ptr+malloc_size); if (Shmid = Shmget (Ipc_private, Shm_size, Shm_mode) ) < 0) printf ("Shmget error"), if ((Shmptr = Shmat (shmid, 0, 0)) = = (void *)-1) printf ("Shmat error");p rintf ("Shared Memor Y attached from%p to%p\n ", (void *) shmptr,  (void *) shmptr+shm_size); if (Shmctl (Shmid, Ipc_rmid, 0) < 0) printf (" Sh Mctl error "); exit (0);}

The MMAP function maps several parts of a file to the process address space. This is conceptually similar to connecting a shared bucket with the Shmat function. The difference between the two is that a bucket mapped with mmap is associated with a file, and the XSI shared bucket has no such association.

For more detailed reference:

Linux inter-process communication-Using shared memory

Linux inter-process communication-using Message Queuing

Linux inter-process communication-using semaphores

Message Queuing, semaphores, and shared memory for IPC Communications