Shulou(Shulou.com)06/01 Report--

This article focuses on "how to solve the process synchronous exit problem of linux using shared memory communication", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to solve the problem of process synchronous exit when linux uses shared memory communication".

Two or more processes communicate using shared memory (shm) and always encounter synchronization problems. The "synchronization problem" here does not refer to the synchronization of process read and write, this is fine with semaphores. The synchronization problem here refers to the synchronization exit problem, which is who quit first and how to know that the other party has quit. For example, process is responsible for reading and writing database A, and process B is responsible for processing data. Then process A will have to exit later than process B, because the data processed by process B will be saved. But A doesn't know when B will quit. An and B are unrelated processes and do not know each other's pid. Their only connection is to read and write the same piece of shared memory. Normally, process B writes an identity in shared memory: process A you can exit, or you can. However, process B may have exited abnormally and did not even have time to write the identity. Secondly, the shared memory is used for data communication, adding such a logo does not feel good, there is a sense of abuse.

Using socket communication does not have this problem, because the exit of process B will cause the socket to disconnect, even if it times out. But shm does not have an agreement to detect these behaviors, and it would be too troublesome to do one on its own. Let's start with shared memory.

Shared memory is managed by the kernel, and the deletion of shared memory opened by one process does not affect the shared memory of another process, even if it is the same shared memory. This is because there is a reference count in the shared memory kernel, and a process using that shared memory will cause the reference count to increase by 1. If one of the processes calls the delete function, only this count of 0 will actually delete the shared memory. In that case, the process that needs to exit last can detect this count.

In System V's shared memory, creating a shared memory initializes a structure:

The code is as follows:

Struct shmid_ds {

Struct ipc_perm shm_perm; / * Ownership and permissions * /

Size_t shm_segsz; / * Size of segment (bytes) * /

Time_t shm_atime; / * Last attach time * /

Time_t shm_dtime; / * Last detach time * /

Time_t shm_ctime; / * Last change time * /

Pid_t shm_cpid; / * PID of creator * /

Pid_t shm_lpid; / * PID of last shmat (2) / shmdt (2) * /

Shmatt_t shm_nattch; / * No. Of current attaches * /

...

}

The structure can be read using the shmctl function, where shm_nattch is the number of processes using the shared memory.

However, now that there is a new POSIX standard, of course we have to use the new standard. The shared memory created by shm_open also has the feature that "one process deletes the open shared memory itself does not affect the shared memory of another process." However, the shared memory created with shm_open no longer has the above structure, so how does the kernel manage shm_open to create shared memory? Look at the following source code:

The code is as follows:

/ * shm_open-open a shared memory file * /

/ * Copyright 2002, Red Hat Inc. * /

# include

# include

# include

# include

# include

# include

Int

Shm_open (const char * name, int oflag, mode_t mode)

{

Int fd

Char shm_ name [path _ MAX+20] = "/ dev/shm/"

/ * skip opening slash * /

If (* name = ='/')

+ + name

/ * create special shared memory file name and leave enough space to

Cause a path/name error if name is too long * /

Strlcpy (shm_name + 9, name, PATH_MAX + 10)

Fd = open (shm_name, oflag, mode)

If (fd! =-1)

{

/ * once open we must add FD_CLOEXEC flag to file descriptor * /

Int flags = fcntl (fd, F_GETFD, 0)

If (flags > = 0)

{

Flags | = FD_CLOEXEC

Flags = fcntl (fd, F_SETFD, flags)

}

/ * on failure, just close file and give up * /

If (flags =-1)

{

Close (fd)

Fd =-1

}

}

Return fd

}

I click, this is to create a normal file, but the location is under / dev/shm (that is, on RAM). Let's take a look at the function shm_unlink that deletes shared memory:

The code is as follows:

/ * shm_unlink-remove a shared memory file * /

/ * Copyright 2002, Red Hat Inc. * /

# include

# include

# include

# include

# include

Int

Shm_unlink (const char * name)

{

Int rc

Char shm_ name [path _ MAX+20] = "/ dev/shm/"

/ * skip opening slash * /

If (* name = ='/')

+ + name

/ * create special shared memory file name and leave enough space to

Cause a path/name error if name is too long * /

Strlcpy (shm_name + 9, name, PATH_MAX + 10)

Rc = unlink (shm_name)

Return rc

}

This is just a normal unlink function. In other words, the POSIX standard shared memory is a file. The so-called "a process to delete its own open shared memory does not affect the shared memory of another process" is equivalent to you use the fstream object to open a file, and then go to the folder to delete the file (that is, the file unlink operation), but the fstream object can also read and write files normally, and there is no reference count. Great, the process can't be synchronized when it exits.

But how can there be a problem that can't be solved under linux? If you can't solve it, it just means you're too lame. Since it's a file, let's start with the file. What is the atomic operation of the file, and it can be counted? Answer: hard links. For example:

The code is as follows:

Xzc@xzc-HP-ProBook-4446s:/dev/shm$ stat abc

File: "abc"

Size: 4 blocks: 8 IO blocks: 4096 ordinary files

Device: 15h/21d Inode:5743159 hard link: 1

Permission: (0664) Uid: (1000 / xzc) Gid: (1000 / xzc)

Last visit: 2015-01-25 21 Vol 27 00.961053098 + 0800

Last modified: 2015-01-25 21 Vol 27 00.961053098 + 0800

Last modified: 2015-01-25 21 Vol 27 00.961053098 + 0800

Creation time:-

Xzc@xzc-HP-ProBook-4446s:/dev/shm$

This hard link can be obtained through the fstat function. However, to implement this means that you need to create a piece of shared memory first, and you need to call the link function to create a hard link when each process references it. The problem is solved, but this will result in multiple files under / dev/shm. This is RAM, although the current servers are quite awesome, but it is not very good to do so. Okay, there's also a flock file lock. Flock uses the LOCK_SH parameter for multiple processes to lock the same file. In this way, process B is locked when initializing shared memory (there can be multiple such processes) and unlocked when exiting (including abnormal exiting). Process A detects this lock on exit. When no lock is found, it means you can exit safely.

The problem of synchronous exit is basically solved. It's too late to write code to verify it, maybe next time.

PS: kernel unlink should also be counted to know if any process is currently opening files and when files should be deleted. We still have to check the information to see if it can be used. In addition, the lsof tool can detect all processes that open the shared memory and the corresponding status. This should also have a corresponding api, but I don't understand it yet.

At this point, I believe you have a deeper understanding of "how to solve the process synchronous exit problem of linux using shared memory communication". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.