devbox
花生_TL007
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

简明Linux系统编程教程_linux编程教程

作者：花生_TL007 | 2024-03-02 15:26:53

赞

踩

linux编程教程

目录

01进程线程概念

02 进程创建函数

03 进程并发

04 进程监控

05 创建线程函数

06 多线程以及线程间的共享

07 进程通信——无名管道

08 测量无名管道的大小

09 无名管道进程通信实例

10 管道双向传输

11 有名管道

12 共享内存

01进程线程概念

程序:（静态的概念）
        源代码
        指令

进程:（动态的概念）
        运行着的程序
        创建销毁 耗费资源大
        进程间独立
        多个进程可以是一个程序
        由内核定义 抽象的实体  开辟一系列资源
                内部的数据结构
                内存
                进程的状态信息
        有id号

任务:
        具体要做的事情
        进程做或线程做

为什么引入线程？
        当要完成一项任务，进程被内核创建 结束时资源被内核回收 进程销毁。这段过程十分地浪费cpu资源 会给liunx系统内核带来非常大的系统消耗。

线程:
        由进程创建 速度比创建进程快
        线程从属于进程，一个进程可以有多个线程
        线程之间共享进程的资源
        某一个线程崩溃 其他会受到影响
        创建销毁线程 耗费资源小

一个程序可以创建多个进程
        每个进程做一件事情
多个进程也可以调用同一个程序
        属调用的资源

实践 获取进程pid

     pid = process id

查看getpid的用户手册

man getpid 

  1. GETPID(2)                   Linux Programmer's Manual                   GETPID(2)
  3. NAME
  4.        getpid, getppid - get process identification
  6. SYNOPSIS
  7.        #include <sys/types.h>
  8.        #include <unistd.h>
  10.        pid_t getpid(void);
  11.        pid_t getppid(void);
  13. DESCRIPTION
  14.        getpid()  returns  the  process ID (PID) of the calling process.  (This is
  15.        often used by routines that generate unique temporary filenames.)
  17.        getppid() returns the process ID of the parent  of  the  calling  process.
  18.        This  will be either the ID of the process that created this process using
  19.        fork(), or, if that process has already terminated, the ID of the  process
  20.        to which this process has been reparented (either init(1) or a "subreaper"
  21.        process defined via the prctl(2) PR_SET_CHILD_SUBREAPER operation).
  23. ERRORS
  24.        These functions are always successful.
  26. CONFORMING TO
  27.        POSIX.1-2001, POSIX.1-2008, 4.3BSD, SVr4.
  29. NOTES
  30.        If the caller's parent is in a  different  PID  namespace  (see  pid_name‐
  31.        spaces(7)), getppid() returns 0.
  32.  
  33.        From  a kernel perspective, the PID (which is shared by all of the threads
  34.        in a multithreaded process) is sometimes also known as the thread group ID
  35.        (TGID).   This  contrasts with the kernel thread ID (TID), which is unique
  36.        for each thread.  For further details, see gettid(2) and the discussion of
  37.        the CLONE_THREAD flag in clone(2).
  38.  
  39.    C library/kernel differences
  40.        From glibc version 2.3.4 up to and including version 2.24, the glibc wrap‐
  41.        per function for getpid() cached PIDs, with the  goal  of  avoiding  addi‐
  42.        tional  system  calls  when a process calls getpid() repeatedly.  Normally
  43.        this caching was invisible, but its correct operation relied on support in
  44.        the  wrapper functions for fork(2), vfork(2), and clone(2): if an applica‐
  45.        tion  bypassed  the  glibc  wrappers  for  these  system  calls  by  using
  46.        syscall(2),  then  a  call to getpid() in the child would return the wrong
  47.        value (to be precise: it would return the PID of the parent process).   In
  48.        addition,  there  were  cases  where getpid() could return the wrong value
  49.        even when invoking clone(2) via the glibc wrapper function.  (For  a  dis‐
  50.        cussion  of  one  such case, see BUGS in clone(2).)  Furthermore, the com‐
  51.        plexity of the caching code had been the source of a few bugs within glibc
  52.        over the years.
  53.  
  54.        Because  of the aforementioned problems, since glibc version 2.25, the PID
  55.        cache is removed: calls to getpid() always invoke the actual system  call,
  56.        rather than returning a cached value.
  57.  
  58.        On Alpha, instead of a pair of getpid() and getppid() system calls, a sin‐
  59.        gle getxpid() system call is provided, which returns a  pair  of  PID  and
  60.        parent  PID.  The glibc getpid() and getppid() wrapper functions transpar‐
  61.        ently deal with this.  See syscall(2) for details regarding register  map‐
  62.        ping.
  63.  
  64. SEE ALSO
  65.        clone(2),  fork(2),  gettid(2),  kill(2), exec(3), mkstemp(3), tempnam(3),
  66.        tmpfile(3), tmpnam(3), credentials(7), pid_namespaces(7)
  67.  
  68. COLOPHON
  69.        This page is part of release 5.10 of the Linux man-pages project.   A  de‐
  70.        scription of the project, information about reporting bugs, and the latest
  71.        version      of      this      page,      can      be       found       at
  72.        https://www.kernel.org/doc/man-pages/.
  73.  
  74. Linux                               2020-11-01                          GETPID(2)

getpid() 当前进程
getppid() 父进程

getpid代码示例01.1

  1. #include<sys/types.h>
  2. #include<unistd.h>
  3. #include<stdio.h>
  4.  
  5. int main(void)
  6. {
  7. 	pid_t pid;
  8. 	while(1)
  9. 	{
  10. 		printf("pid=%d\n",getpid());
  11. 		printf("ppid=%d\n",getppid());
  12. 		printf("hello world\n");
  13. 		sleep(1);
  14. 	}
  15. 	return 0;
  16. }

--gcc pid.c

--./a.out      //分析结果

 打开终端运行命令查看进程数

# pstree -p

总的来看 a.out的进程树

Systemd(1)——systemd(2578)——gnome-terminal-(9474)——bash(9492)——a.out(19740)

systemd(1):所有进程的父进程

=init(1)（历史）(一回事)

02 进程创建函数

使用fork创建进程

查看手册man  fork()

  1. FORK(2)                                 Linux Programmer's Manual                                FORK(2)
  3. NAME
  4.        fork - create a child process
  6. SYNOPSIS
  7.        #include <sys/types.h>
  8.        #include <unistd.h>
  10.        pid_t fork(void);
  11.  
  12. DESCRIPTION
  13.        fork()  creates a new process by duplicating the calling process.  The new process is referred to
  14.        as the child process.  The calling process is referred to as the parent process.
  16.        The child process and the parent process run in separate memory spaces.  At the  time  of  fork()
  17.        both memory spaces have the same content.  Memory writes, file mappings (mmap(2)), and unmappings
  18.        (munmap(2)) performed by one of the processes do not affect the other.
  20.        The child process is an exact duplicate of the parent process except for the following points:
  22.        *  The child has its own unique process ID, and this PID does not match the ID  of  any  existing
  23.           process group (setpgid(2)) or session.
  25.        *  The child's parent process ID is the same as the parent's process ID.
  27.        *  The child does not inherit its parent's memory locks (mlock(2), mlockall(2)).
  29.        *  Process  resource  utilizations  (getrusage(2))  and CPU time counters (times(2)) are reset to
  30.           zero in the child.
  32.        *  The child's set of pending signals is initially empty (sigpending(2)).
  34.        *  The child does not inherit semaphore adjustments from its parent (semop(2)).
  36.        *  The child does not inherit process-associated record locks from its  parent  (fcntl(2)).   (On
  37.           the  other  hand, it does inherit fcntl(2) open file description locks and flock(2) locks from
  38.           its parent.)
  40.        *  The child does not inherit timers from its parent (setitimer(2), alarm(2), timer_create(2)).
  42.        *  The  child  does  not  inherit  outstanding  asynchronous  I/O  operations  from  its   parent
  43.           (aio_read(3), aio_write(3)), nor does it inherit any asynchronous I/O contexts from its parent
  44.           (see io_setup(2)).
  46.        The process attributes in the preceding list are all specified in POSIX.1.  The parent and  child
  47.        also differ with respect to the following Linux-specific process attributes:
  49.        *  The  child  does not inherit directory change notifications (dnotify) from its parent (see the
  50.           description of F_NOTIFY in fcntl(2)).
  52.        *  The prctl(2) PR_SET_PDEATHSIG setting is reset so that the child does  not  receive  a  signal
  53.           when its parent terminates.
  55.        *  The  default  timer slack value is set to the parent's current timer slack value.  See the de‐
  56.           scription of PR_SET_TIMERSLACK in prctl(2).
  58.        *  Memory mappings that have been marked with the madvise(2) MADV_DONTFORK flag are not inherited
  59.           across a fork().
  61.        *  Memory in address ranges that have been marked with the madvise(2) MADV_WIPEONFORK flag is ze‐
  62.           roed in the child after a fork().  (The MADV_WIPEONFORK setting remains in place for those ad‐
  63.           dress ranges in the child.)
  65.        *  The termination signal of the child is always SIGCHLD (see clone(2)).
  67.        *  The  port  access  permission  bits set by ioperm(2) are not inherited by the child; the child
  68.           must turn on any bits that it requires using ioperm(2).
  70.        Note the following further points:
  72.        *  The child process is created with a single thread—the one that called fork().  The entire vir‐
  73.           tual  address space of the parent is replicated in the child, including the states of mutexes,
  74.           condition variables, and other pthreads objects; the use of pthread_atfork(3) may  be  helpful
  75.           for dealing with problems that this can cause.
  77.        *  After  a  fork()  in a multithreaded program, the child can safely call only async-signal-safe
  78.           functions (see signal-safety(7)) until such time as it calls execve(2).
  80.        *  The child inherits copies of the parent's set of open file descriptors.  Each file  descriptor
  81.           in  the child refers to the same open file description (see open(2)) as the corresponding file
  82.           descriptor in the parent.  This means that the two file descriptors  share  open  file  status
  83.           flags,  file  offset,  and  signal-driven  I/O attributes (see the description of F_SETOWN and
  84.           F_SETSIG in fcntl(2)).
  86.        *  The child inherits copies of the parent's set of open message queue descriptors (see  mq_over‐
  87.           view(7)).  Each file descriptor in the child refers to the same open message queue description
  88.           as the corresponding file descriptor in the parent.  This means that the two file  descriptors
  89.           share the same flags (mq_flags).
  91.        *  The  child  inherits  copies  of  the parent's set of open directory streams (see opendir(3)).
  92.           POSIX.1 says that the corresponding directory streams in the parent and child  may  share  the
  93.           directory stream positioning; on Linux/glibc they do not.
  94.  
  95. RETURN VALUE
  96.        On  success,  the  PID  of  the child process is returned in the parent, and 0 is returned in the
  97.        child.  On failure, -1 is returned in the parent, no child process is created, and errno  is  set
  98.        appropriately.
  99.  
  100. ERRORS
  101.        EAGAIN A  system-imposed  limit  on the number of threads was encountered.  There are a number of
  102.               limits that may trigger this error:
  103.  
  104.               *  the RLIMIT_NPROC soft resource limit (set via setrlimit(2)), which limits the number of
  105.                  processes and threads for a real user ID, was reached;
  106.  
  107.               *  the  kernel's  system-wide limit on the number of processes and threads, /proc/sys/ker‐
  108.                  nel/threads-max, was reached (see proc(5));
  109.  
  110.               *  the maximum number of PIDs, /proc/sys/kernel/pid_max, was reached (see proc(5)); or
  112.               *  the PID limit (pids.max) imposed by the cgroup "process number" (PIDs)  controller  was
  113.                  reached.
  115.        EAGAIN The  caller  is operating under the SCHED_DEADLINE scheduling policy and does not have the
  116.               reset-on-fork flag set.  See sched(7).
  118.        ENOMEM fork() failed to allocate the necessary kernel structures because memory is tight.
  120.        ENOMEM An attempt was made to create a child process in a PID namespace whose "init" process  has
  121.               terminated.  See pid_namespaces(7).
  123.        ENOSYS fork()  is  not supported on this platform (for example, hardware without a Memory-Manage‐
  124.               ment Unit).
  126.        ERESTARTNOINTR (since Linux 2.6.17)
  127.               System call was interrupted by a signal and will be restarted.  (This  can  be  seen  only
  128.               during a trace.)
  130. CONFORMING TO
  131.        POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
  133. NOTES
  134.        Under  Linux, fork() is implemented using copy-on-write pages, so the only penalty that it incurs
  135.        is the time and memory required to duplicate the parent's page tables, and  to  create  a  unique
  136.        task structure for the child.
  138.    C library/kernel differences
  139.        Since version 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrap‐
  140.        per that is provided as part of the NPTL threading implementation  invokes  clone(2)  with  flags
  141.        that  provide the same effect as the traditional system call.  (A call to fork() is equivalent to
  142.        a call to clone(2) specifying flags as just SIGCHLD.)  The glibc wrapper invokes  any  fork  han‐
  143.        dlers that have been established using pthread_atfork(3).
  145. EXAMPLES
  146.        See pipe(2) and wait(2).
  148. SEE ALSO
  149.        clone(2), execve(2), exit(2), setrlimit(2), unshare(2), vfork(2), wait(2), daemon(3), pthread_at‐
  150.        fork(3), capabilities(7), credentials(7)
  152. COLOPHON
  153.        This page is part of release 5.10 of the Linux man-pages project.  A description of the  project,
  154.        information  about  reporting  bugs,  and  the  latest  version  of  this  page,  can be found at
  155.        https://www.kernel.org/doc/man-pages/.
  157. Linux                                          2020-06-09                                        FORK(2)

fork代码示例02.1

  1. #include<sys/types.h>
  2. #include<unistd.h>
  3. #include<stdio.h>
  4. int main(void)
  5. {
  6.     pid_t pid;
  7.     pid=fork();
  8.     printf("pid=%d\n",pid);
  9.     printf("hello world\n");
  10.     return 0;
  11. }

 fork代码示例02.2

  1. #include<sys/types.h>
  2. #include<unistd.h>
  3. #include <stdio.h>
  4. int main(void)
  5. {
  6. 		pid_t pid1,pid2;
  7. 		pid1=fork();
  8. 		pid2=fork();
  9. 		printf("pid1=%d,pid2=%d\n",pid1,pid2);
  10.         while(1);
  11. 	return 0;
  12. }

输出

:~/Desktop# ./a.out

pid1=24387B,pid2=24388C

pid1=24387B,pid2=0

pid1=0,pid2=24389D

pid1=0,pid2=0

分析程序执行的流程 

 加入循环 调出进程树 pstree -p

 

   可以分析进程id大概就是这样执行的  不过进程之间是独立的 不一定谁先执行，

03 进程并发

为什么用到多进程?
        希望父 子进程（独立分割）执行不同的内容

并发执行代码示例03.1

  1. #include<sys/types.h>
  2. #include<unistd.h>
  3. #include <stdio.h>
  4. int main(void)
  5. {
  6.        pid_t pid;
  7.         pid=fork();
  8.         if(pid>0){ //父进程
  9.                 while(1){
  10.                         printf("hello world\n");
  11.                         sleep(1);
  12.                 }
  13.         }
  14.         else if(pid==0){
  15.                 while(1){
  16.                         printf("good moring\n");
  17.                         sleep(1);
  18.                 }
  19.         }
  20.         else{
  21.                 printf("err\n");
  22.         }
  23.         return 0;
  24. }

Hello world 和 good moring 并行执行

 不能根据输出结果 判断谁先执行

微观：默认情况下(内核) 父进程先调用
        父进程在创建 子进程的过程  正在执行中

父进程的结束 不会影响子进程的执行？

        状态影响

 状态影响代码示例03.2

  1. #include<sys/types.h>
  2. #include<unistd.h>
  3. #include <stdio.h>
  4. int main(void)
  5. {
  6.        pid_t pid;
  7. int count = 0;
  8.         pid=fork();
  9.         if(pid>0){ //父进程
  10.         for(int i=0;i<10;i++){
  11.         
  12.                         printf("hello world count=%d\n",count++);
  13.                         sleep(1);}
  14.                    }
  15.         else if(pid==0){
  16.                 while(1){
  17.                         printf("good moring count=%d\n",count++);
  18.                         sleep(1);
  19.                 }
  20.         }
  21.         else{
  22.                 printf("err\n");
  23.         }
  24.         return 0;
  25. }

输出

 可以看出父进程的结束 并没有影响的子进程的执行状态。

...........................................................................................................................................................

有没有手段！进程同步监控子进程的状态...

怎样才能影响！任务之间的通信和同步...

04 进程监控

父进程监控子进程状态的改变（结束;停止;）

man wait

  1. WAIT(1POSIX)                          POSIX Programmer's Manual                          WAIT(1POSIX)
  3. PROLOG
  4.        This  manual  page is part of the POSIX Programmer's Manual.  The Linux implementation of this
  5.        interface may differ (consult the corresponding Linux manual page for details of Linux  behav‐
  6.        ior), or the interface may not be implemented on Linux.
  8. NAME
  9.        wait — await process completion
  11. SYNOPSIS
  12.        wait [pid...]
  14. DESCRIPTION
  15.        When an asynchronous list (see Section 2.9.3.1, Examples) is started by the shell, the process
  16.        ID of the last command in each element of the asynchronous list shall become known in the cur‐
  17.        rent shell execution environment; see Section 2.12, Shell Execution Environment.
  18.  
  19.        If  the wait utility is invoked with no operands, it shall wait until all process IDs known to
  20.        the invoking shell have terminated and exit with a zero exit status.
  21.  
  22.        If one or more pid operands are specified that represent known process IDs, the  wait  utility
  23.        shall  wait  until all of them have terminated. If one or more pid operands are specified that
  24.        represent unknown process IDs, wait shall treat them as if they were known  process  IDs  that
  25.        exited  with  exit  status 127. The exit status returned by the wait utility shall be the exit
  26.        status of the process requested by the last pid operand.
  27.  
  28.        The known process IDs are applicable only for invocations of wait in the current shell  execu‐
  29.        tion environment.
  30.  
  31. OPTIONS
  32.        None.
  33.  
  34. OPERANDS
  35.        The following operand shall be supported:
  36.  
  37.        pid       One of the following:
  38.  
  39.                   1. The  unsigned  decimal integer process ID of a command, for which the utility is
  40.                      to wait for the termination.
  41.  
  42.                   2. A job control job ID (see the Base Definitions volume of  POSIX.1‐2017,  Section
  43.                      3.204,  Job  Control  Job  ID)  that identifies a background process group to be
  44.                      waited for. The job control job ID notation is applicable only  for  invocations
  45.                      of wait in the current shell execution environment; see Section 2.12, Shell Exe‐
  46.                      cution Environment.  The exit status of wait shall be  determined  by  the  last
  47.                      command in the pipeline.
  48.  
  49.                      Note:     The  job  control job ID type of pid is only available on systems sup‐
  50.                                porting the User Portability Utilities option.
  51.  
  52. STDIN
  53.        Not used.
  54.  
  55. INPUT FILES
  56.        None.
  57.  
  58. ENVIRONMENT VARIABLES
  59.        The following environment variables shall affect the execution of wait:
  60.  
  61.        LANG      Provide a default value for the internationalization variables  that  are  unset  or
  62.                  null.  (See the Base Definitions volume of POSIX.1‐2017, Section 8.2, International‐
  63.                  ization Variables for the precedence of internationalization variables used  to  de‐
  64.                  termine the values of locale categories.)
  65.  
  66.        LC_ALL    If  set  to  a non-empty string value, override the values of all the other interna‐
  67.                  tionalization variables.
  68.  
  69.        LC_CTYPE  Determine the locale for the interpretation of sequences of bytes of  text  data  as
  70.                  characters  (for  example,  single-byte as opposed to multi-byte characters in argu‐
  71.                  ments).
  73.        LC_MESSAGES
  74.                  Determine the locale that should be used to affect the format and contents of  diag‐
  75.                  nostic messages written to standard error.
  77.        NLSPATH   Determine the location of message catalogs for the processing of LC_MESSAGES.
  79. ASYNCHRONOUS EVENTS
  80.        Default.
  82. STDOUT
  83.        Not used.
  85. STDERR
  86.        The standard error shall be used only for diagnostic messages.
  88. OUTPUT FILES
  89.        None.
  91. EXTENDED DESCRIPTION
  92.        None.
  94. EXIT STATUS
  95.        If  one  or more operands were specified, all of them have terminated or were not known by the
  96.        invoking shell, and the status of the last operand specified is known, then the exit status of
  97.        wait  shall be the exit status information of the command indicated by the last operand speci‐
  98.        fied. If the process terminated abnormally due to the receipt of a  signal,  the  exit  status
  99.        shall  be  greater than 128 and shall be distinct from the exit status generated by other sig‐
  100.        nals, but the exact value is unspecified. (See the kill -l option.) Otherwise, the wait  util‐
  101.        ity shall exit with one of the following values:
  103.            0   The  wait utility was invoked with no operands and all process IDs known by the invok‐
  104.                ing shell have terminated.
  106.        1‐126   The wait utility detected an error.
  108.          127   The command identified by the last pid operand specified is unknown.
  110. CONSEQUENCES OF ERRORS
  111.        Default.
  113.        The following sections are informative.
  115. APPLICATION USAGE
  116.        On most implementations, wait is a shell built-in. If it is called in a subshell  or  separate
  117.        utility execution environment, such as one of the following:
  119.            (wait)
  120.            nohup wait ...
  121.            find . -exec wait ... \;
  122.  
  123.        it  returns  immediately  because there are no known process IDs to wait for in those environ‐
  124.        ments.
  125.  
  126.        Historical implementations of interactive shells have discarded the exit status of  terminated
  127.        background  processes  before each shell prompt. Therefore, the status of background processes
  128.        was usually lost unless it terminated while wait was waiting for it. This could be  a  serious
  129.        problem when a job that was expected to run for a long time actually terminated quickly with a
  130.        syntax or initialization error because the exit status returned was usually zero  if  the  re‐
  131.        quested  process  ID was not found. This volume of POSIX.1‐2017 requires the implementation to
  132.        keep the status of terminated jobs available until the status is requested,  so  that  scripts
  133.        like:
  134.  
  135.            j1&
  136.            p1=$!
  137.            j2&
  138.            wait $p1
  139.            echo Job 1 exited with status $?
  140.            wait $!
  141.            echo Job 2 exited with status $?
  142.  
  143.        work  without  losing status on any of the jobs. The shell is allowed to discard the status of
  144.        any process if it determines that the application cannot get the process ID for  that  process
  145.        from  the  shell. It is also required to remember only {CHILD_MAX} number of processes in this
  146.        way. Since the only way to get the process ID from the shell is by using the '!'  shell param‐
  147.        eter,  the shell is allowed to discard the status of an asynchronous list if "$!" was not ref‐
  148.        erenced before another asynchronous list was started. (This means that the shell only  has  to
  149.        keep  the  status  of  the last asynchronous list started if the application did not reference
  150.        "$!".  If the implementation of the shell is smart enough to determine  that  a  reference  to
  151.        "$!" was not saved anywhere that the application can retrieve it later, it can use this infor‐
  152.        mation to trim the list of saved information. Note also that a successful call to wait with no
  153.        operands discards the exit status of all asynchronous lists.)
  154.  
  155.        If the exit status of wait is greater than 128, there is no way for the application to know if
  156.        the waited-for process exited with that value or was killed by a signal.  Since most utilities
  157.        exit  with  small values, there is seldom any ambiguity. Even in the ambiguous cases, most ap‐
  158.        plications just need to know that the asynchronous job failed; it does not matter  whether  it
  159.        detected an error and failed or was killed and did not complete its job normally.
  160.  
  161. EXAMPLES
  162.        Although  the  exact value used when a process is terminated by a signal is unspecified, if it
  163.        is known that a signal terminated a process, a script can still reliably determine which  sig‐
  164.        nal by using kill as shown by the following script:
  165.  
  166.            sleep 1000&
  167.            pid=$!
  168.            kill -kill $pid
  169.            wait $pid
  170.            echo $pid was terminated by a SIG$(kill -l $?) signal.
  171.  
  172.        If the following sequence of commands is run in less than 31 seconds:
  173.  
  174.            sleep 257 | sleep 31 &
  175.            jobs -l %%
  176.  
  177.        either of the following commands returns the exit status of the second sleep in the pipeline:
  178.  
  179.            wait <pid of sleep 31>
  180.            wait %%
  181.  
  182. RATIONALE
  183.        The  description  of  wait does not refer to the waitpid() function from the System Interfaces
  184.        volume of POSIX.1‐2017 because that would needlessly overspecify this interface. However,  the
  185.        wording  means that wait is required to wait for an explicit process when it is given an argu‐
  186.        ment so that the status information of other processes is not consumed. Historical implementa‐
  187.        tions  use  the  wait() function defined in the System Interfaces volume of POSIX.1‐2017 until
  188.        wait() returns the requested process ID or finds that the requested process  does  not  exist.
  189.        Because  this  means  that  a shell script could not reliably get the status of all background
  190.        children if a second background job was ever started before the first job finished, it is rec‐
  191.        ommended  that  the  wait utility use a method such as the functionality provided by the wait‐
  192.        pid() function.
  193.  
  194.        The ability to wait for multiple pid operands was adopted from the KornShell.
  195.  
  196.        This new functionality was added because it is needed to determine  the  exit  status  of  any
  197.        asynchronous list accurately. The only compatibility problem that this change creates is for a
  198.        script like
  199.  
  200.            while sleep 60 do
  201.                job& echo Job started $(date) as $!  done
  202.  
  203.        which causes the shell to monitor all of the jobs started until the script terminates or  runs
  204.        out of memory. This would not be a problem if the loop did not reference "$!" or if the script
  205.        would occasionally wait for jobs it started.
  206.  
  207. FUTURE DIRECTIONS
  208.        None.
  209.  
  210. SEE ALSO
  211.        Chapter 2, Shell Command Language, kill, sh
  212.  
  213.        The Base Definitions volume of POSIX.1‐2017, Section 3.204, Job Control Job ID, Chapter 8, En‐
  214.        vironment Variables
  215.  
  216.        The System Interfaces volume of POSIX.1‐2017, wait()
  217.  
  218. COPYRIGHT
  219.        Portions  of  this  text  are  reprinted  and  reproduced  in  electronic  form  from IEEE Std
  220.        1003.1-2017, Standard for  Information  Technology  --  Portable  Operating  System  Interface
  221.        (POSIX),  The  Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the
  222.        Institute of Electrical and Electronics Engineers, Inc and The Open Group.  In  the  event  of
  223.        any  discrepancy  between  this version and the original IEEE and The Open Group Standard, the
  224.        original IEEE and The Open Group Standard is the referee document. The original  Standard  can
  225.        be obtained online at http://www.opengroup.org/unix/online.html .
  226.  
  227.        Any  typographical  or formatting errors that appear in this page are most likely to have been
  228.        introduced during the conversion of the source files to man page format. To  report  such  er‐
  229.        rors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .
  230.  
  231. IEEE/The Open Group                              2017                                    WAIT(1POSIX)

 wait代码示例04.1  传入参数让子进程延时 全部子进程延时完毕后父进程结束

  1. #include <sys/types.h>
  2. #include <sys/wait.h>
  3. #include <stdio.h>
  4. #include <stdlib.h>
  5. #include <unistd.h>
  6.  
  7. //run model: ./a.out 10 5 15  (three child process, after 10, 5, 15seconds, they are over)
  8. int main(int argc, char *argv[])
  9. {
  10. 	pid_t child_pid;
  11. 	int numDead;
  12. 	int i;
  13.  
  14. 	for(i = 1; i < argc; i++)
  15. 	{
  16. 		switch(fork())
  17. 		{
  18. 			case -1:
  19. 				perror("fork()");
  20. 				exit(0);
  21. 			case 0:
  22. 				printf("Child %d started with PID = %d, sleeping %s seconds\n", i, getpid(), argv[i]);
  23. 				sleep(atoi(argv[i]));
  24. 				exit(0);
  25. 			default:
  26. 				break;
  27. 		}
  28. 	}
  29.  
  30. 	numDead = 0;
  31.  
  32. 	while(1)
  33. 	{
  34. 		child_pid = wait(NULL);
  35.  
  36. 		if(child_pid == -1)
  37. 		{
  38. 			printf("No more children, Byebye!\n");
  39. 			exit(0);
  40. 		}
  41.  
  42. 		numDead++;
  43. 		printf("wait() returned child PID : %d(numDead = %d)\n", child_pid, numDead);
  44. 	}
  45. }

输出 

05 创建线程函数

复习下 线程 进程的概念

进程:（动态的概念）（运行着的程序）
        创建销毁 耗费资源大
        进程间独立
        多个进程可以是一个程序
        由内核定义 抽象的实体  开辟一系列资源
        有id号

线程:
        由进程创建
        进程结束 线程也将结束
        线程从属于进程，一个进程可以有多个线程
        线程之间共享进程的资源
        某一个崩溃 其他会受到影响
        创建销毁 耗费资源小

线程创建函数pthread_create接收四个参数

int pthread_create(pthread_t *thread,const pthread_attr_t *attr,void *(*start rourtine)(void),void *arg);
        pthread_t *thread 输出类型参数  
        const pthread_attr_t *attr 结构体指针 放置线程的属性
        void *(*start rourtine)(void)指针函数  返回指针 接收参数指针  实际上接就是 线程执行的内容
        void *arg 传递现线程的参数

函数执行成功 返回0  错误返回error number

查看手册man pthread_cread

  1. PTHREAD_CREATE(3)                        Linux Programmer's Manual                       PTHREAD_CREATE(3)
  3. NAME
  4.        pthread_create - create a new thread
  6. SYNOPSIS
  7.        #include <pthread.h>
  9.        int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
  10.                           void *(*start_routine) (void *), void *arg);
  11.  
  12.        Compile and link with -pthread.
  13.  
  14. DESCRIPTION
  15.        The  pthread_create()  function  starts a new thread in the calling process.  The new thread starts
  16.        execution by invoking start_routine(); arg is passed as the sole argument of start_routine().
  18.        The new thread terminates in one of the following ways:
  20.        * It calls pthread_exit(3), specifying an exit status value that is available to another thread  in
  21.          the same process that calls pthread_join(3).
  23.        * It  returns  from  start_routine().  This is equivalent to calling pthread_exit(3) with the value
  24.          supplied in the return statement.
  26.        * It is canceled (see pthread_cancel(3)).
  28.        * Any of the threads in the process calls exit(3), or  the  main  thread  performs  a  return  from
  29.          main().  This causes the termination of all threads in the process.
  31.        The  attr  argument points to a pthread_attr_t structure whose contents are used at thread creation
  32.        time  to  determine  attributes  for  the  new  thread;  this  structure   is   initialized   using
  33.        pthread_attr_init(3)  and  related functions.  If attr is NULL, then the thread is created with de‐
  34.        fault attributes.
  36.        Before returning, a successful call to pthread_create() stores the ID of the new thread in the buf‐
  37.        fer  pointed  to  by  thread; this identifier is used to refer to the thread in subsequent calls to
  38.        other pthreads functions.
  39.  
  40.        The new thread inherits a copy of the creating thread's signal mask (pthread_sigmask(3)).  The  set
  41.        of  pending  signals  for the new thread is empty (sigpending(2)).  The new thread does not inherit
  42.        the creating thread's alternate signal stack (sigaltstack(2)).
  43.  
  44.        The new thread inherits the calling thread's floating-point environment (fenv(3)).
  45.  
  46.        The initial value of the new thread's CPU-time clock is 0 (see pthread_getcpuclockid(3)).
  47.  
  48.    Linux-specific details
  49.        The new thread inherits copies of the calling thread's capability sets  (see  capabilities(7))  and
  50.        CPU affinity mask (see sched_setaffinity(2)).
  51.  
  52. RETURN VALUE
  53.        On  success,  pthread_create() returns 0; on error, it returns an error number, and the contents of
  54.        *thread are undefined.
  55.  
  56. ERRORS
  57.        EAGAIN Insufficient resources to create another thread.
  58.  
  59.        EAGAIN A system-imposed limit on the number of threads was encountered.  There are a number of lim‐
  60.               its  that  may  trigger  this  error:  the  RLIMIT_NPROC  soft resource limit (set via setr‐
  61.               limit(2)), which limits the number of processes and threads for a real user ID, was reached;
  62.               the  kernel's  system-wide  limit  on  the  number  of processes and threads, /proc/sys/ker‐
  63.               nel/threads-max, was reached (see proc(5)); or the maximum number  of  PIDs,  /proc/sys/ker‐
  64.               nel/pid_max, was reached (see proc(5)).
  66.        EINVAL Invalid settings in attr.
  68.        EPERM  No permission to set the scheduling policy and parameters specified in attr.
  70. ATTRIBUTES
  71.        For an explanation of the terms used in this section, see attributes(7).
  73.        ┌─────────────────┬───────────────┬─────────┐
  74.        │Interface        │ Attribute     │ Value   │
  75.        ├─────────────────┼───────────────┼─────────┤
  76.        │pthread_create() │ Thread safety │ MT-Safe │
  77.        └─────────────────┴───────────────┴─────────┘
  79. CONFORMING TO
  80.        POSIX.1-2001, POSIX.1-2008.
  82. NOTES
  83.        See  pthread_self(3)  for  further information on the thread ID returned in *thread by pthread_cre‐
  84.        ate().  Unless real-time scheduling policies are being employed, after a call to  pthread_create(),
  85.        it is indeterminate which thread—the caller or the new thread—will next execute.
  87.        A thread may either be joinable or detached.  If a thread is joinable, then another thread can call
  88.        pthread_join(3) to wait for the thread to terminate and fetch its exit status.  Only when a  termi‐
  89.        nated  joinable  thread  has been joined are the last of its resources released back to the system.
  90.        When a detached thread terminates, its resources are automatically released back to the system:  it
  91.        is  not  possible  to join with the thread in order to obtain its exit status.  Making a thread de‐
  92.        tached is useful for some types of daemon threads whose exit status the application does  not  need
  93.        to  care  about.   By  default, a new thread is created in a joinable state, unless attr was set to
  94.        create the thread in a detached state (using pthread_attr_setdetachstate(3)).
  96.        Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at  the  time  the
  97.        program  started has any value other than "unlimited", then it determines the default stack size of
  98.        new threads.  Using pthread_attr_setstacksize(3), the stack size attribute can be explicitly set in
  99.        the  attr argument used to create a thread, in order to obtain a stack size other than the default.
  100.        If the RLIMIT_STACK resource limit is set to "unlimited", a per-architecture value is used for  the
  101.        stack size.  Here is the value for a few architectures:
  103.               ┌─────────────┬────────────────────┐
  104.               │Architecture │ Default stack size │
  105.               ├─────────────┼────────────────────┤
  106.               │i386         │               2 MB │
  107.               ├─────────────┼────────────────────┤
  108.               │IA-64        │              32 MB │
  109.               ├─────────────┼────────────────────┤
  110.               │PowerPC      │               4 MB │
  111.               ├─────────────┼────────────────────┤
  112.               │S/390        │               2 MB │
  113.               ├─────────────┼────────────────────┤
  114.               │Sparc-32     │               2 MB │
  115.               ├─────────────┼────────────────────┤
  116.               │Sparc-64     │               4 MB │
  117.               ├─────────────┼────────────────────┤
  118.               │x86_64       │               2 MB │
  119.               └─────────────┴────────────────────┘
  120. BUGS
  121.        In  the  obsolete  LinuxThreads  implementation,  each  of the threads in a process has a different
  122.        process ID.  This is in violation of the POSIX threads specification, and is  the  source  of  many
  123.        other nonconformances to the standard; see pthreads(7).
  125. EXAMPLES
  126.        The  program below demonstrates the use of pthread_create(), as well as a number of other functions
  127.        in the pthreads API.
  129.        In the following run, on a system providing the NPTL threading implementation, the stack  size  de‐
  130.        faults to the value given by the "stack size" resource limit:
  132.            $ ulimit -s
  133.            8192            # The stack size limit is 8 MB (0x800000 bytes)
  134.            $ ./a.out hola salut servus
  135.            Thread 1: top of stack near 0xb7dd03b8; argv_string=hola
  136.            Thread 2: top of stack near 0xb75cf3b8; argv_string=salut
  137.            Thread 3: top of stack near 0xb6dce3b8; argv_string=servus
  138.            Joined with thread 1; returned value was HOLA
  139.            Joined with thread 2; returned value was SALUT
  140.            Joined with thread 3; returned value was SERVUS
  141.  
  142.        In  the  next  run,  the program explicitly sets a stack size of 1 MB (using pthread_attr_setstack‐
  143.        size(3)) for the created threads:
  144.  
  145.            $ ./a.out -s 0x100000 hola salut servus
  146.            Thread 1: top of stack near 0xb7d723b8; argv_string=hola
  147.            Thread 2: top of stack near 0xb7c713b8; argv_string=salut
  148.            Thread 3: top of stack near 0xb7b703b8; argv_string=servus
  149.            Joined with thread 1; returned value was HOLA
  150.            Joined with thread 2; returned value was SALUT
  151.            Joined with thread 3; returned value was SERVUS
  152.  
  153.    Program source
  154.  
  155.        #include <pthread.h>
  156.        #include <string.h>
  157.        #include <stdio.h>
  158.        #include <stdlib.h>
  159.        #include <unistd.h>
  160.        #include <errno.h>
  161.        #include <ctype.h>
  162.  
  163.        #define handle_error_en(en, msg) \
  164.                do { errno = en; perror(msg); exit(EXIT_FAILURE); } while (0)
  165.  
  166.        #define handle_error(msg) \
  167.                do { perror(msg); exit(EXIT_FAILURE); } while (0)
  168.  
  169.        struct thread_info {    /* Used as argument to thread_start() */
  170.            pthread_t thread_id;        /* ID returned by pthread_create() */
  171.            int       thread_num;       /* Application-defined thread # */
  172.            char     *argv_string;      /* From command-line argument */
  173.        };
  174.  
  175.        /* Thread start function: display address near top of our stack,
  176.           and return upper-cased copy of argv_string */
  177.  
  178.        static void *
  179.        thread_start(void *arg)
  180.        {
  181.            struct thread_info *tinfo = arg;
  182.            char *uargv;
  183.  
  184.            printf("Thread %d: top of stack near %p; argv_string=%s\n",
  185.                    tinfo->thread_num, &p, tinfo->argv_string);
  186.  
  187.            uargv = strdup(tinfo->argv_string);
  188.            if (uargv == NULL)
  189.                handle_error("strdup");
  190.  
  191.            for (char *p = uargv; *p != '\0'; p++)
  192.                *p = toupper(*p);
  193.  
  194.            return uargv;
  195.        }
  196.  
  197.        int
  198.        main(int argc, char *argv[])
  199.        {
  200.            int s, opt, num_threads;
  201.            pthread_attr_t attr;
  202.            size_t stack_size;
  203.            void *res;
  204.  
  205.            /* The "-s" option specifies a stack size for our threads */
  206.  
  207.            stack_size = -1;
  208.            while ((opt = getopt(argc, argv, "s:")) != -1) {
  209.                switch (opt) {
  210.                case 's':
  211.                    stack_size = strtoul(optarg, NULL, 0);
  212.                    break;
  213.  
  214.                default:
  215.                    fprintf(stderr, "Usage: %s [-s stack-size] arg...\n",
  216.                            argv[0]);
  217.                    exit(EXIT_FAILURE);
  218.                }
  219.            }
  220.  
  221.            num_threads = argc - optind;
  222.  
  223.            /* Initialize thread creation attributes */
  224.  
  225.            s = pthread_attr_init(&attr);
  226.            if (s != 0)
  227.                handle_error_en(s, "pthread_attr_init");
  228.  
  229.            if (stack_size > 0) {
  230.                s = pthread_attr_setstacksize(&attr, stack_size);
  231.                if (s != 0)
  232.                    handle_error_en(s, "pthread_attr_setstacksize");
  233.            }
  234.  
  235.            /* Allocate memory for pthread_create() arguments */
  236.  
  237.            struct thread_info *tinfo = calloc(num_threads, sizeof(*tinfo));
  238.            if (tinfo == NULL)
  239.                handle_error("calloc");
  240.  
  241.            /* Create one thread for each command-line argument */
  242.  
  243.            for (int tnum = 0; tnum < num_threads; tnum++) {
  244.                tinfo[tnum].thread_num = tnum + 1;
  245.                tinfo[tnum].argv_string = argv[optind + tnum];
  246.  
  247.                /* The pthread_create() call stores the thread ID into
  248.                   corresponding element of tinfo[] */
  249.  
  250.                s = pthread_create(&tinfo[tnum].thread_id, &attr,
  251.                                   &thread_start, &tinfo[tnum]);
  252.                if (s != 0)
  253.                    handle_error_en(s, "pthread_create");
  254.            }
  255.  
  256.            /* Destroy the thread attributes object, since it is no
  257.               longer needed */
  258.  
  259.            s = pthread_attr_destroy(&attr);
  260.            if (s != 0)
  261.                handle_error_en(s, "pthread_attr_destroy");
  262.  
  263.            /* Now join with each thread, and display its returned value */
  264.  
  265.            for (int tnum = 0; tnum < num_threads; tnum++) {
  266.                s = pthread_join(tinfo[tnum].thread_id, &res);
  267.                if (s != 0)
  268.                    handle_error_en(s, "pthread_join");
  269.  
  270.                printf("Joined with thread %d; returned value was %s\n",
  271.                        tinfo[tnum].thread_num, (char *) res);
  272.                free(res);      /* Free memory allocated by thread */
  273.            }
  274.  
  275.            free(tinfo);
  276.            exit(EXIT_SUCCESS);
  277.        }
  278.  
  279. SEE ALSO
  280.        getrlimit(2), pthread_attr_init(3), pthread_cancel(3), pthread_detach(3), pthread_equal(3),
  281.        pthread_exit(3), pthread_getattr_np(3), pthread_join(3), pthread_self(3),
  282.        pthread_setattr_default_np(3), pthreads(7)
  284. COLOPHON
  285.        This page is part of release 5.10 of the Linux man-pages project.  A description of the project,
  286.        information about reporting bugs, and the latest version of this page, can be found at
  287.        https://www.kernel.org/doc/man-pages/.
  289. Linux                                           2020-11-01                               PTHREAD_CREATE(3)

进程等待线程函数 pthread_join

man pthread_join

  1. PTHREAD_JOIN(3)                                Linux Programmer's Manual                               PTHREAD_JOIN(3)
  3. NAME
  4.        pthread_join - join with a terminated thread
  6. SYNOPSIS
  7.        #include <pthread.h>
  9.        int pthread_join(pthread_t thread, void **retval);
  10.  
  11.        Compile and link with -pthread.
  12.  
  13. DESCRIPTION
  14.        The  pthread_join() function waits for the thread specified by thread to terminate.  If that thread has already
  15.        terminated, then pthread_join() returns immediately.  The thread specified by thread must be joinable.
  17.        If retval is not NULL, then pthread_join() copies the exit status of the target thread (i.e.,  the  value  that
  18.        the  target  thread  supplied to pthread_exit(3)) into the location pointed to by retval.  If the target thread
  19.        was canceled, then PTHREAD_CANCELED is placed in the location pointed to by retval.
  21.        If multiple threads simultaneously try to join with the same thread, the results are undefined.  If the  thread
  22.        calling  pthread_join()  is  canceled,  then  the  target thread will remain joinable (i.e., it will not be de‐
  23.        tached).
  25. RETURN VALUE
  26.        On success, pthread_join() returns 0; on error, it returns an error number.
  27.  
  28. ERRORS
  29.        EDEADLK
  30.               A deadlock was detected (e.g., two threads tried to join with each other); or thread specifies the call‐
  31.               ing thread.
  32.  
  33.        EINVAL thread is not a joinable thread.
  34.  
  35.        EINVAL Another thread is already waiting to join with this thread.
  36.  
  37.        ESRCH  No thread with the ID thread could be found.
  38.  
  39. ATTRIBUTES
  40.        For an explanation of the terms used in this section, see attributes(7).
  42.        ┌───────────────┬───────────────┬─────────┐
  43.        │Interface      │ Attribute     │ Value   │
  44.        ├───────────────┼───────────────┼─────────┤
  45.        │pthread_join() │ Thread safety │ MT-Safe │
  46.        └───────────────┴───────────────┴─────────┘
  48. CONFORMING TO
  49.        POSIX.1-2001, POSIX.1-2008.
  51. NOTES
  52.        After a successful call to pthread_join(), the caller is guaranteed that the target thread has terminated.  The
  53.        caller may then choose to do any clean-up that is required after termination of the thread (e.g., freeing  mem‐
  54.        ory or other resources that were allocated to the target thread).
  56.        Joining with a thread that has previously been joined results in undefined behavior.
  58.        Failure  to  join  with a thread that is joinable (i.e., one that is not detached), produces a "zombie thread".
  59.        Avoid doing this, since each zombie thread consumes some system resources, and when enough zombie threads  have
  60.        accumulated, it will no longer be possible to create new threads (or processes).
  62.        There is no pthreads analog of waitpid(-1, &status, 0), that is, "join with any terminated thread".  If you be‐
  63.        lieve you need this functionality, you probably need to rethink your application design.
  65.        All of the threads in a process are peers: any thread can join with any other thread in the process.
  67. EXAMPLES
  68.        See pthread_create(3).
  70. SEE ALSO
  71.        pthread_cancel(3), pthread_create(3), pthread_detach(3), pthread_exit(3), pthread_tryjoin_np(3), pthreads(7)
  73. COLOPHON
  74.        This page is part of release 5.10 of the Linux man-pages project.  A description of  the  project,  information
  75.        about    reporting    bugs,    and    the    latest    version    of    this    page,    can    be   found   at
  76.        https://www.kernel.org/doc/man-pages/.
  78. Linux                                                 2020-06-09                                       PTHREAD_JOIN(3)

创建线程代码示例05.1

  1. #include <pthread.h>
  2. #include <stdio.h>
  3. #include <unistd.h>
  4. #include <stdlib.h>
  5.  
  6. void *thread_function(void *arg);
  7.  
  8. int main(void)
  9. {
  10. 	pthread_t pthread;
  11. 	int ret;
  12. 	int count = 8;
  13.  
  14. 	ret = pthread_create(&pthread, NULL, thread_function, &count);
  15. 	if(ret != 0)
  16. 	{
  17. 		perror("pthread_create");
  18. 		exit(1);
  19. 	}
  20.  
  21. 	pthread_join(pthread, NULL);
  22. 	printf("The thread is over, process is over too.\n");
  23.  
  24. 	return 0;
  25. }
  26.  
  27. void *thread_function(void *arg)
  28. {
  29. 	int i;
  30. 	printf("Thread begins running\n");
  31.  
  32. 	for(i = 0; i < *(int *)arg; i++)
  33. 	{
  34. 		printf("Hello world\n");
  35. 		sleep(1);
  36. 	}
  37. 	return NULL;
  38. }

 

06 多线程以及线程间的共享

创建多线程的方法与创建一个线程的方法是一样的

代码示例 06.1

  1. #include <pthread.h>
  2. #include <stdio.h>
  3. #include <unistd.h>
  4. #include <stdlib.h>
  5.  
  6. void *thread1_function(void *arg);
  7. void *thread2_function(void *arg);
  8.  
  9. int count = 0;//线程可见
  10.  
  11. int main(void)
  12. {
  13. 	pthread_t pthread1, pthread2;
  14. 	int ret;
  15.  
  16. 	ret = pthread_create(&pthread1, NULL, thread1_function, NULL);
  17. 	if(ret != 0)
  18. 	{
  19. 		perror("pthread_create");
  20. 		exit(1);
  21. 	}
  22.  
  23. 	ret = pthread_create(&pthread2, NULL, thread2_function, NULL);
  24. 	if(ret != 0)
  25. 	{
  26. 		perror("pthread_create");
  27. 		exit(1);
  28. 	}
  29.  
  30. 	pthread_join(pthread1, NULL);
  31. 	pthread_join(pthread2, NULL);
  32. 	printf("The thread is over, process is over too.\n");
  33.  
  34. 	return 0;
  35. }
  36.  
  37. void *thread1_function(void *arg)
  38. {
  39. 	printf("Thread1 begins running\n");
  40.  
  41. 	while(1)
  42. 	{
  43. 		printf("Thread1 count = %d\n", count++);
  44. 		sleep(1);
  45. 	}
  46. 	return NULL;
  47. }
  48.  
  49. void *thread2_function(void *arg)
  50. {
  51. 	printf("Thread2 begins running\n");
  52. 	while(1)
  53. 	{
  54. 		printf("Thread2 count = %d\n", count++);
  55. 		sleep(1);
  56. 	}
  57. 	return NULL;
  58. }

 

07 进程通信——无名管道

进程间的通信收手段

管道 pipe
        命名管道
        无名管道  单向

man pipe

  1. PIPE(2)                                        Linux Programmer's Manual                                       PIPE(2)
  3. NAME
  4.        pipe, pipe2 - create pipe
  6. SYNOPSIS
  7.        #include <unistd.h>
  9.        /* On Alpha, IA-64, MIPS, SuperH, and SPARC/SPARC64; see NOTES */
  10.        struct fd_pair {
  11.            long fd[2];
  12.        };
  13.        struct fd_pair pipe();
  14.  
  15.        /* On all other architectures */
  16.        int pipe(int pipefd[2]);
  17.  
  18.        #define _GNU_SOURCE             /* See feature_test_macros(7) */
  19.        #include <fcntl.h>              /* Obtain O_* constant definitions */
  20.        #include <unistd.h>
  21.  
  22.        int pipe2(int pipefd[2], int flags);
  23.  
  24. DESCRIPTION
  25.        pipe()  creates a pipe, a unidirectional data channel that can be used for interprocess communication.  The ar‐
  26.        ray pipefd is used to return two file descriptors referring to the ends of the pipe.  pipefd[0] refers  to  the
  27.        read  end  of  the  pipe.  pipefd[1] refers to the write end of the pipe.  Data written to the write end of the
  28.        pipe is buffered by the kernel until it is read from the read end  of  the  pipe.   For  further  details,  see
  29.        pipe(7).
  31.        If flags is 0, then pipe2() is the same as pipe().  The following values can be bitwise ORed in flags to obtain
  32.        different behavior:
  34.        O_CLOEXEC
  35.               Set the close-on-exec (FD_CLOEXEC) flag on the two new file descriptors.  See  the  description  of  the
  36.               same flag in open(2) for reasons why this may be useful.
  38.        O_DIRECT (since Linux 3.4)
  39.               Create a pipe that performs I/O in "packet" mode.  Each write(2) to the pipe is dealt with as a separate
  40.               packet, and read(2)s from the pipe will read one packet at a time.  Note the following points:
  42.               *  Writes of greater than PIPE_BUF bytes (see pipe(7)) will be split into multiple  packets.   The  con‐
  43.                  stant PIPE_BUF is defined in <limits.h>.
  45.               *  If  a read(2) specifies a buffer size that is smaller than the next packet, then the requested number
  46.                  of bytes are read, and the excess bytes in the packet are discarded.  Specifying  a  buffer  size  of
  47.                  PIPE_BUF will be sufficient to read the largest possible packets (see the previous point).
  49.               *  Zero-length  packets  are not supported.  (A read(2) that specifies a buffer size of zero is a no-op,
  50.                  and returns 0.)
  52.               Older kernels that do not support this flag will indicate this via an EINVAL error.
  54.               Since Linux 4.5, it is possible to change the O_DIRECT setting of a pipe file descriptor using fcntl(2).
  56.        O_NONBLOCK
  57.               Set the O_NONBLOCK file status flag on the open file descriptions referred to by the new  file  descrip‐
  58.               tors.  Using this flag saves extra calls to fcntl(2) to achieve the same result.
  60. RETURN VALUE
  61.        On  success,  zero  is  returned.  On error, -1 is returned, errno is set appropriately, and pipefd is left un‐
  62.        changed.
  64.        On Linux (and other systems), pipe() does not modify pipefd on failure.  A requirement standardizing  this  be‐
  65.        havior  was  added in POSIX.1-2008 TC2.  The Linux-specific pipe2() system call likewise does not modify pipefd
  66.        on failure.
  68. ERRORS
  69.        EFAULT pipefd is not valid.
  71.        EINVAL (pipe2()) Invalid value in flags.
  73.        EMFILE The per-process limit on the number of open file descriptors has been reached.
  75.        ENFILE The system-wide limit on the total number of open files has been reached.
  77.        ENFILE The user hard limit on memory that can be allocated for pipes has been reached and  the  caller  is  not
  78.               privileged; see pipe(7).
  80. VERSIONS
  81.        pipe2() was added to Linux in version 2.6.27; glibc support is available starting with version 2.9.
  82.  
  83. CONFORMING TO
  84.        pipe(): POSIX.1-2001, POSIX.1-2008.
  86.        pipe2() is Linux-specific.
  88. NOTES
  89.        The  System V ABI on some architectures allows the use of more than one register for returning multiple values;
  90.        several architectures (namely, Alpha, IA-64, MIPS, SuperH, and SPARC/SPARC64) (ab)use this feature in order  to
  91.        implement the pipe() system call in a functional manner: the call doesn't take any arguments and returns a pair
  92.        of file descriptors as the return value on success.  The glibc pipe() wrapper function transparently deals with
  93.        this.  See syscall(2) for information regarding registers used for storing second file descriptor.
  95. EXAMPLES
  96.        The  following program creates a pipe, and then fork(2)s to create a child process; the child inherits a dupli‐
  97.        cate set of file descriptors that refer to the same pipe.  After the fork(2), each process closes the file  de‐
  98.        scriptors  that it doesn't need for the pipe (see pipe(7)).  The parent then writes the string contained in the
  99.        program's command-line argument to the pipe, and the child reads this string a byte at a time from the pipe and
  100.        echoes it on standard output.
  102.    Program source
  103.        #include <sys/types.h>
  104.        #include <sys/wait.h>
  105.        #include <stdio.h>
  106.        #include <stdlib.h>
  107.        #include <unistd.h>
  108.        #include <string.h>
  110.        int
  111.        main(int argc, char *argv[])
  112.        {
  113.            int pipefd[2];
  114.            pid_t cpid;
  115.            char buf;
  117.            if (argc != 2) {
  118.                fprintf(stderr, "Usage: %s <string>\n", argv[0]);
  119.                exit(EXIT_FAILURE);
  120.            }
  122.            if (pipe(pipefd) == -1) {
  123.                perror("pipe");
  124.                exit(EXIT_FAILURE);
  125.            }
  127.            cpid = fork();
  128.            if (cpid == -1) {
  129.                perror("fork");
  130.                exit(EXIT_FAILURE);
  131.            }
  133.            if (cpid == 0) {    /* Child reads from pipe */
  134.                close(pipefd[1]);          /* Close unused write end */
  136.                while (read(pipefd[0], &buf, 1) > 0)
  137.                    write(STDOUT_FILENO, &buf, 1);
  139.                write(STDOUT_FILENO, "\n", 1);
  140.                close(pipefd[0]);
  141.                _exit(EXIT_SUCCESS);
  143.            } else {            /* Parent writes argv[1] to pipe */
  144.                close(pipefd[0]);          /* Close unused read end */
  145.                write(pipefd[1], argv[1], strlen(argv[1]));
  146.                close(pipefd[1]);          /* Reader will see EOF */
  147.                wait(NULL);                /* Wait for child */
  148.                exit(EXIT_SUCCESS);
  149.            }
  150.        }
  152. SEE ALSO
  153.        fork(2), read(2), socketpair(2), splice(2), tee(2), vmsplice(2), write(2), popen(3), pipe(7)
  155. COLOPHON
  156.        This  page  is  part of release 5.10 of the Linux man-pages project.  A description of the project, information
  157.        about   reporting   bugs,    and    the    latest    version    of    this    page,    can    be    found    at
  158.        https://www.kernel.org/doc/man-pages/.
  160. Linux                                                 2020-06-09                                               PIPE(2)

现实现 利用管道 父进程向子进程写入数据。

代码示例07.1

  1. /*
  2. 	parent process: write pipe
  3. 	child  process: read  pipe
  4. */
  5. #include <unistd.h>
  6. #include <sys/types.h>
  7. #include <stdio.h>
  8.  
  9. int main(void)
  10. {
  11. 	int fd[2];
  12. 	int pid;
  13.  
  14. 	if(pipe(fd) == -1)
  15. 		perror("pipe");
  16.  
  17. 	pid = fork();
  18. 	if(pid > 0)  //parent process
  19. 	{
  20. 		close(fd[0]);
  21. 		sleep(5);
  22. 		write(fd[1], "ab", 2);
  23.  
  24. 		while(1);
  25. 	}
  26. 	else if(pid == 0)
  27. 	{
  28. 		char ch[2];
  29.  
  30. 		printf("Child process is waiting for data: \n");
  31. 		close(fd[1]);
  32. 		read(fd[0], ch, 2);//没有写入  阻塞等待
  33. 		printf("Read from pipe: %s\n", ch);
  34. 	}
  35.  
  36. 	return 0;
  37. }

08 测量无名管道的大小

向管道循环注入数据测试管道能够装载的最大值

代码示例08.1.c

  1. #include <unistd.h>
  2. #include <sys/types.h>
  3. #include <stdio.h>
  4. #include <sys/wait.h>
  5.  
  6. int main(void)
  7. {
  8. 	pid_t pid;
  9. 	int fd[2];
  10.  
  11. 	if(pipe(fd) == -1)
  12. 		perror("pipe");
  13.  
  14. 	pid = fork();
  15.  
  16. 	if(pid == 0)  //child process: write to the pipe
  17. 	{
  18. 		char ch = '*';
  19. 		int n = 0;
  20.  
  21. 		close(fd[0]);
  22.  
  23. 		while(1)
  24. 		{
  25. 			write(fd[1], &ch, 1);
  26. 			printf("count = %d\n", ++n);
  27. 		}
  28. 	}
  29. 	else if(pid > 0)  //parent process: wait until child process is over
  30. 	{
  31. 		waitpid(pid, NULL, 0);
  32. 	}
  33. }

09 无名管道进程通信实例

父进程等待之进程的输入。

代码示例09.1.c

  1. #include <unistd.h>
  2. #include <sys/types.h>
  3. #include <stdio.h>
  4. #include <sys/wait.h>
  5.  
  6. int main(void)
  7. {
  8. 	pid_t pid;
  9. 	int fd[2];
  10.  
  11. 	if(pipe(fd) == -1)
  12. 		perror("pipe");
  13.  
  14. 	pid = fork();
  15.  
  16. 	if(pid == 0)
  17. 	{
  18. 		char tmp[100];
  19.  
  20. 		close(fd[0]);
  21.  
  22. 		while(1)
  23. 		{
  24. 			scanf("%s", tmp);
  25. 			write(fd[1], tmp, sizeof(tmp));
  26. 		}
  27. 	}
  28. 	else if(pid > 0)
  29. 	{
  30. 		char tmp[100];
  31. 		close(fd[1]);
  32.  
  33. 		while(1)
  34. 		{
  35. 			printf("Parent process is waiting for the data from pipe:\n");
  36. 			read(fd[0], tmp, sizeof(tmp));
  37. 			printf("read from pipe: %s\n", tmp);
  38. 		}
  39. 	}
  40.  
  41. 	return 0;
  42. }

10 管道双向传输

父进程实现小写转换大写传回子进程输出。

代码示例10.1.c

  1. #include <unistd.h>
  2. #include <sys/types.h>
  3. #include <stdio.h>
  4. #include <sys/wait.h>
  5. #include <string.h>
  6. #include <ctype.h>
  7.  
  8. int main(void)
  9. {
  10. 	pid_t pid;
  11. 	int fd[2];
  12. 	int fd2[2];
  13.  
  14. 	if(pipe(fd) == -1)
  15. 		perror("pipe");
  16. 	if(pipe(fd2) == -1)
  17. 		perror("pipe");
  18.  
  19. 	pid = fork();
  20.  
  21. 	if(pid == 0)
  22. 	{
  23. 		char tmp[100];
  24. 		int i;
  25.  
  26. 		close(fd[1]);
  27. 		close(fd2[0]);
  28.  
  29. 		while(1)
  30. 		{
  31. 			memset(tmp, '\0', sizeof(tmp));
  32. 			read(fd[0], tmp, sizeof(tmp));
  33.  
  34. 			for(i = 0; i < sizeof(tmp); i++)
  35. 				tmp[i] = toupper(tmp[i]);
  36.  
  37. 			write(fd2[1], tmp, sizeof(tmp));
  38. 		}
  39. 	}
  40. 	else if(pid > 0)
  41. 	{
  42. 		char tmp[100];
  43. 		close(fd[0]);
  44. 		close(fd2[1]);
  45.  
  46. 		while(1)
  47. 		{
  48. 			memset(tmp, '\0', sizeof(tmp));
  49. 			gets(tmp);
  50. 			write(fd[1], tmp, sizeof(tmp));
  51.  
  52. 			memset(tmp, '\0', sizeof(tmp));
  53. 			read(fd2[0], tmp, sizeof(tmp));
  54. 			printf("After change: %s\n", tmp);
  55. 		}
  56. 	}
  57.  
  58. 	return 0;
  59. }

11 有名管道

概念引出
        无名管道只适用于有亲缘关系的进程间。
        没有亲缘关系的两个进程是否可以进行通信 ?

查看liunx编程手册
        通过man man 得知 序号3是库调用 1是shell命名 2是系统调用
        man 3 mkfifo

       1   Executable programs or shell commands
       2   System calls (functions provided by the kernel)
       3   Library calls (functions within program libraries)
       4   Special files (usually found in /dev)
       5   File formats and conventions, e.g. /etc/passwd
       6   Games
       7   Miscellaneous  (including  macro  packages and conventions), e.g.
           man(7), groff(7), man-pages(7)
       8   System administration commands (usually only for root)
       9   Kernel routines [Non standard]

  1. MKFIFO(3)                   Linux Programmer's Manual                   MKFIFO(3)
  3. NAME
  4.        mkfifo, mkfifoat - make a FIFO special file (a named pipe)
  6. SYNOPSIS
  7.        #include <sys/types.h>
  8.        #include <sys/stat.h>
  10.        int mkfifo(const char *pathname, mode_t mode);
  11.  
  12.        #include <fcntl.h>           /* Definition of AT_* constants */
  13.        #include <sys/stat.h>
  14.  
  15.        int mkfifoat(int dirfd, const char *pathname, mode_t mode);
  16.  
  17.    Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
  19.        mkfifoat():
  20.            Since glibc 2.10:
  21.                _POSIX_C_SOURCE >= 200809L
  22.            Before glibc 2.10:
  23.                _ATFILE_SOURCE
  25. DESCRIPTION
  26.        mkfifo() makes a FIFO special file with name pathname.  mode specifies the
  27.        FIFO's permissions.  It is modified by the process's umask  in  the  usual
  28.        way: the permissions of the created file are (mode & ~umask).
  30.        A  FIFO  special file is similar to a pipe, except that it is created in a
  31.        different way.  Instead of being an anonymous  communications  channel,  a
  32.        FIFO special file is entered into the filesystem by calling mkfifo().
  34.        Once  you  have  created  a FIFO special file in this way, any process can
  35.        open it for reading or writing, in the same way as an ordinary file.  How‐
  36.        ever, it has to be open at both ends simultaneously before you can proceed
  37.        to do any input or output operations on it.  Opening a  FIFO  for  reading
  38.        normally  blocks until some other process opens the same FIFO for writing,
  39.        and vice versa.  See fifo(7) for  nonblocking  handling  of  FIFO  special
  40.        files.
  42.    mkfifoat()
  43.        The  mkfifoat() function operates in exactly the same way as mkfifo(), ex‐
  44.        cept for the differences described here.
  46.        If the pathname given in pathname is relative, then it is interpreted rel‐
  47.        ative  to  the  directory referred to by the file descriptor dirfd (rather
  48.        than relative to the current working directory of the calling process,  as
  49.        is done by mkfifo() for a relative pathname).
  51.        If  pathname  is  relative  and  dirfd is the special value AT_FDCWD, then
  52.        pathname is interpreted relative to the current working directory  of  the
  53.        calling process (like mkfifo()).
  55.        If pathname is absolute, then dirfd is ignored.
  57. RETURN VALUE
  58.        On  success mkfifo() and mkfifoat() return 0.  In the case of an error, -1
  59.        is returned (in which case, errno is set appropriately).
  61. ERRORS
  62.        EACCES One of the directories in pathname did not allow  search  (execute)
  63.               permission.
  65.        EDQUOT The  user's  quota  of  disk blocks or inodes on the filesystem has
  66.               been exhausted.
  68.        EEXIST pathname already exists.  This includes the case where pathname  is
  69.               a symbolic link, dangling or not.
  71.        ENAMETOOLONG
  72.               Either the total length of pathname is greater than PATH_MAX, or an
  73.               individual filename component has a length greater  than  NAME_MAX.
  74.               In  the  GNU  system, there is no imposed limit on overall filename
  75.               length, but some filesystems may place limits on the  length  of  a
  76.               component.
  78.        ENOENT A  directory  component in pathname does not exist or is a dangling
  79.               symbolic link.
  81.        ENOSPC The directory or filesystem has no room for the new file.
  83.        ENOTDIR
  84.               A component used as a directory in pathname is not, in fact, a  di‐
  85.               rectory.
  87.        EROFS  pathname refers to a read-only filesystem.
  89.        The following additional errors can occur for mkfifoat():
  91.        EBADF  dirfd is not a valid file descriptor.
  93.        ENOTDIR
  94.               pathname  is  a relative path and dirfd is a file descriptor refer‐
  95.               ring to a file other than a directory.
  97. VERSIONS
  98.        mkfifoat() was added to glibc in version 2.4.   It  is  implemented  using
  99.        mknodat(2), available on Linux since kernel 2.6.16.
  101. ATTRIBUTES
  102.        For an explanation of the terms used in this section, see attributes(7).
  104.        ┌─────────────────────┬───────────────┬─────────┐
  105.        │Interface            │ Attribute     │ Value   │
  106.        ├─────────────────────┼───────────────┼─────────┤
  107.        │mkfifo(), mkfifoat() │ Thread safety │ MT-Safe │
  108.        └─────────────────────┴───────────────┴─────────┘
  109. CONFORMING TO
  110.        mkfifo(): POSIX.1-2001, POSIX.1-2008.
  112.        mkfifoat(): POSIX.1-2008.
  114. SEE ALSO
  115.        mkfifo(1),   close(2),  open(2),  read(2),  stat(2),  umask(2),  write(2),
  116.        fifo(7)
  118. COLOPHON
  119.        This page is part of release 5.10 of the Linux man-pages project.   A  de‐
  120.        scription of the project, information about reporting bugs, and the latest
  121.        version      of      this      page,      can      be       found       at
  122.        https://www.kernel.org/doc/man-pages/.
  124. GNU                                 2020-08-13                          MKFIFO(3)

代码示例11.1.c 创建有名管道 一直向管道读取

  1. #include <stdio.h>
  2. #include <sys/stat.h>
  3. #include <sys/types.h>
  4. #include <unistd.h>
  5. #include <fcntl.h>
  6. #include <string.h>
  7.  
  8. int main(void)
  9. {
  10.     int ret;
  11.     int fd;
  12.     char buf[100];
  13.  
  14.     ret = mkfifo("my_fifo", 0666);
  15.     if(ret != 0)
  16.         perror("mkfifo");
  17.  
  18.     printf("Prepare reading from named pipe:\n");
  19.  
  20.     fd = open("my_fifo", O_RDWR);
  21.     if(fd == -1)
  22.         perror("open");
  23.  
  24.     while(1)
  25.     {
  26.         memset(buf, '\0', sizeof(buf));
  27.         read(fd, buf, sizeof(buf));
  28.         printf("Read from named pipe: %s\n", buf);
  29.         sleep(1);
  30.     }
  31.  
  32.     return 0;
  33. }

代码示例11.2.c 用户交互 向管道写入数据

  1. #include <stdio.h>
  2. #include <sys/stat.h>
  3. #include <sys/types.h>
  4. #include <unistd.h>
  5. #include <fcntl.h>
  6. #include <string.h>
  7. #include <stdlib.h>
  8.  
  9. int main(int argc, char *argv[])
  10. {
  11.     int fd;
  12.     char buf[100];
  13.  
  14.     fd = open("my_fifo", O_WRONLY);
  15.     if(fd == -1)
  16.         perror("open");
  17.  
  18.     if(argc == 1)
  19.     {
  20.         printf("Please send something to the named pipe:\n");
  21.         exit(EXIT_FAILURE);
  22.     }
  23.  
  24.     strcpy(buf, argv[1]);
  25.     write(fd, buf, sizeof(buf));
  26.     printf("Write to the pipe: %s\n", buf);
  27.  
  28.     return 0;
  29. }

 

12 共享内存

man shmget

  1. SHMGET(2)                                                   Linux Programmer's Manual                                                  SHMGET(2)
  3. NAME
  4.        shmget - allocates a System V shared memory segment
  6. SYNOPSIS
  7.        #include <sys/ipc.h>
  8.        #include <sys/shm.h>
  10.        int shmget(key_t key, size_t size, int shmflg);
  11.  
  12. DESCRIPTION
  13.        shmget()  returns the identifier of the System V shared memory segment associated with the value of the argument key.  It may be used ei‐
  14.        ther to obtain the identifier of a previously created shared memory segment (when shmflg is zero and key does not have the value IPC_PRI‐
  15.        VATE), or to create a new set.
  17.        A  new shared memory segment, with size equal to the value of size rounded up to a multiple of PAGE_SIZE, is created if key has the value
  18.        IPC_PRIVATE or key isn't IPC_PRIVATE, no shared memory segment corresponding to key exists, and IPC_CREAT is specified in shmflg.
  20.        If shmflg specifies both IPC_CREAT and IPC_EXCL and a shared memory segment already exists for key, then shmget() fails with errno set to
  21.        EEXIST.  (This is analogous to the effect of the combination O_CREAT | O_EXCL for open(2).)
  23.        The value shmflg is composed of:
  25.        IPC_CREAT
  26.               Create  a  new segment.  If this flag is not used, then shmget() will find the segment associated with key and check to see if the
  27.               user has permission to access the segment.
  29.        IPC_EXCL
  30.               This flag is used with IPC_CREAT to ensure that this call creates the segment.  If the segment already exists, the call fails.
  32.        SHM_HUGETLB (since Linux 2.6)
  33.               Allocate the segment using "huge pages."  See the Linux kernel source file Documentation/admin-guide/mm/hugetlbpage.rst  for  fur‐
  34.               ther information.
  36.        SHM_HUGE_2MB, SHM_HUGE_1GB (since Linux 3.8)
  37.               Used  in  conjunction with SHM_HUGETLB to select alternative hugetlb page sizes (respectively, 2 MB and 1 GB) on systems that sup‐
  38.               port multiple hugetlb page sizes.
  40.               More generally, the desired huge page size can be configured by encoding the base-2 logarithm of the desired page size in the  six
  41.               bits at the offset SHM_HUGE_SHIFT.  Thus, the above two constants are defined as:
  43.                   #define SHM_HUGE_2MB    (21 << SHM_HUGE_SHIFT)
  44.                   #define SHM_HUGE_1GB    (30 << SHM_HUGE_SHIFT)
  46.               For some additional details, see the discussion of the similarly named constants in mmap(2).
  48.        SHM_NORESERVE (since Linux 2.6.15)
  49.               This flag serves the same purpose as the mmap(2) MAP_NORESERVE flag.  Do not reserve swap space for this segment.  When swap space
  50.               is reserved, one has the guarantee that it is possible to modify the segment.  When swap space  is  not  reserved  one  might  get
  51.               SIGSEGV  upon  a  write if no physical memory is available.  See also the discussion of the file /proc/sys/vm/overcommit_memory in
  52.               proc(5).
  54.        In addition to the above flags, the least significant 9 bits of shmflg specify the permissions granted to the owner, group,  and  others.
  55.        These  bits  have the same format, and the same meaning, as the mode argument of open(2).  Presently, execute permissions are not used by
  56.        the system.
  58.        When a new shared memory segment is created, its contents are initialized to zero values, and its  associated  data  structure,  shmid_ds
  59.        (see shmctl(2)), is initialized as follows:
  61.        • shm_perm.cuid and shm_perm.uid are set to the effective user ID of the calling process.
  63.        • shm_perm.cgid and shm_perm.gid are set to the effective group ID of the calling process.
  65.        • The least significant 9 bits of shm_perm.mode are set to the least significant 9 bit of shmflg.
  67.        • shm_segsz is set to the value of size.
  69.        • shm_lpid, shm_nattch, shm_atime, and shm_dtime are set to 0.
  71.        • shm_ctime is set to the current time.
  73.        If the shared memory segment already exists, the permissions are verified, and a check is made to see if it is marked for destruction.
  75. RETURN VALUE
  76.        On success, a valid shared memory identifier is returned.  On error, -1 is returned, and errno is set to indicate the error.
  78. ERRORS
  79.        On failure, errno is set to one of the following:
  81.        EACCES The  user does not have permission to access the shared memory segment, and does not have the CAP_IPC_OWNER capability in the user
  82.               namespace that governs its IPC namespace.
  84.        EEXIST IPC_CREAT and IPC_EXCL were specified in shmflg, but a shared memory segment already exists for key.
  86.        EINVAL A new segment was to be created and size is less than SHMMIN or greater than SHMMAX.
  88.        EINVAL A segment for the given key exists, but size is greater than the size of that segment.
  90.        ENFILE The system-wide limit on the total number of open files has been reached.
  92.        ENOENT No segment exists for the given key, and IPC_CREAT was not specified.
  94.        ENOMEM No memory could be allocated for segment overhead.
  96.        ENOSPC All possible shared memory IDs have been taken (SHMMNI), or allocating a segment of the requested size would cause the  system  to
  97.               exceed the system-wide limit on shared memory (SHMALL).
  99.        EPERM  The SHM_HUGETLB flag was specified, but the caller was not privileged (did not have the CAP_IPC_LOCK capability).
  101. CONFORMING TO
  102.        POSIX.1-2001, POSIX.1-2008, SVr4.
  104.        SHM_HUGETLB and SHM_NORESERVE are Linux extensions.
  106. NOTES
  107.        The inclusion of <sys/types.h> and <sys/ipc.h> isn't required on Linux or by any version of POSIX.  However, some old implementations re‐
  108.        quired the inclusion of these header files, and the SVID also documented their inclusion.  Applications intended to be portable  to  such
  109.        old systems may need to include these header files.
  111.        IPC_PRIVATE  isn't  a flag field but a key_t type.  If this special value is used for key, the system call ignores all but the least sig‐
  112.        nificant 9 bits of shmflg and creates a new shared memory segment.
  114.    Shared memory limits
  115.        The following limits on shared memory segment resources affect the shmget() call:
  117.        SHMALL System-wide limit on the total amount of shared memory, measured in units of the system page size.
  119.               On Linux, this limit can be read and modified via /proc/sys/kernel/shmall.  Since Linux 3.16, the default value for this limit is:
  121.                   ULONG_MAX - 2^24
  123.               The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation on  allocations.   This
  124.               value,  rather than ULONG_MAX, was chosen as the default to prevent some cases where historical applications simply raised the ex‐
  125.               isting limit without first checking its current value.  Such applications would cause the value to overflow if the limit  was  set
  126.               at ULONG_MAX.
  128.               From Linux 2.4 up to Linux 3.15, the default value for this limit was:
  130.                   SHMMAX / PAGE_SIZE * (SHMMNI / 16)
  132.               If  SHMMAX  and  SHMMNI  were not modified, then multiplying the result of this formula by the page size (to get a value in bytes)
  133.               yielded a value of 8 GB as the limit on the total memory used by all shared memory segments.
  135.        SHMMAX Maximum size in bytes for a shared memory segment.
  137.               On Linux, this limit can be read and modified via /proc/sys/kernel/shmmax.  Since Linux 3.16, the default value for this limit is:
  139.                   ULONG_MAX - 2^24
  141.               The effect of this value (which is suitable for both 32-bit and 64-bit systems) is to impose no limitation  on  allocations.   See
  142.               the description of SHMALL for a discussion of why this default value (rather than ULONG_MAX) is used.
  144.               From Linux 2.2 up to Linux 3.15, the default value of this limit was 0x2000000 (32 MB).
  146.               Because  it  is not possible to map just part of a shared memory segment, the amount of virtual memory places another limit on the
  147.               maximum size of a usable segment: for example, on i386 the largest segments that can be mapped have a size of around  2.8 GB,  and
  148.               on x86-64 the limit is around 127 TB.
  150.        SHMMIN Minimum  size  in bytes for a shared memory segment: implementation dependent (currently 1 byte, though PAGE_SIZE is the effective
  151.               minimum size).
  153.        SHMMNI System-wide limit on the number of shared memory segments.  In Linux 2.2, the default value for this limit was  128;  since  Linux
  154.               2.4, the default value is 4096.
  155.  
  156.               On Linux, this limit can be read and modified via /proc/sys/kernel/shmmni.
  157.  
  158.        The implementation has no specific limits for the per-process maximum number of shared memory segments (SHMSEG).
  160.    Linux notes
  161.        Until version 2.3.30, Linux would return EIDRM for a shmget() on a shared memory segment scheduled for deletion.
  163. BUGS
  164.        The name choice IPC_PRIVATE was perhaps unfortunate, IPC_NEW would more clearly show its function.
  166. EXAMPLES
  167.        See shmop(2).
  169. SEE ALSO
  170.        memfd_create(2), shmat(2), shmctl(2), shmdt(2), ftok(3), capabilities(7), shm_overview(7), sysvipc(7)
  172. COLOPHON
  173.        This  page  is  part of release 5.10 of the Linux man-pages project.  A description of the project, information about reporting bugs, and
  174.        the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/.
  176. Linux                                                              2020-04-11                                                          SHMGET(2)

man shmdt

  1. SHMOP(2)                                                    Linux Programmer's Manual                                                   SHMOP(2)
  3. NAME
  4.        shmat, shmdt - System V shared memory operations
  6. SYNOPSIS
  7.        #include <sys/types.h>
  8.        #include <sys/shm.h>
  10.        void *shmat(int shmid, const void *shmaddr, int shmflg);
  11.  
  12.        int shmdt(const void *shmaddr);
  13.  
  14. DESCRIPTION
  15.    shmat()
  16.        shmat()  attaches  the System V shared memory segment identified by shmid to the address space of the calling process.  The attaching ad‐
  17.        dress is specified by shmaddr with one of the following criteria:
  19.        • If shmaddr is NULL, the system chooses a suitable (unused) page-aligned address to attach the segment.
  21.        • If shmaddr isn't NULL and SHM_RND is specified in shmflg, the attach occurs at the address equal to shmaddr rounded down to the nearest
  22.          multiple of SHMLBA.
  24.        • Otherwise, shmaddr must be a page-aligned address at which the attach occurs.
  26.        In addition to SHM_RND, the following flags may be specified in the shmflg bit-mask argument:
  28.        SHM_EXEC (Linux-specific; since Linux 2.6.9)
  29.               Allow the contents of the segment to be executed.  The caller must have execute permission on the segment.
  31.        SHM_RDONLY
  32.               Attach  the  segment for read-only access.  The process must have read permission for the segment.  If this flag is not specified,
  33.               the segment is attached for read and write access, and the process must have read and write permission for the segment.  There  is
  34.               no notion of a write-only shared memory segment.
  36.        SHM_REMAP (Linux-specific)
  37.               This  flag specifies that the mapping of the segment should replace any existing mapping in the range starting at shmaddr and con‐
  38.               tinuing for the size of the segment.  (Normally, an EINVAL error would result if a mapping already exists in this address  range.)
  39.               In this case, shmaddr must not be NULL.
  41.        The  brk(2)  value of the calling process is not altered by the attach.  The segment will automatically be detached at process exit.  The
  42.        same segment may be attached as a read and as a read-write one, and more than once, in the process's address space.
  44.        A successful shmat() call updates the members of the shmid_ds structure (see shmctl(2)) associated with the shared memory segment as fol‐
  45.        lows:
  47.        • shm_atime is set to the current time.
  49.        • shm_lpid is set to the process-ID of the calling process.
  51.        • shm_nattch is incremented by one.
  53.    shmdt()
  54.        shmdt()  detaches  the  shared  memory segment located at the address specified by shmaddr from the address space of the calling process.
  55.        The to-be-detached segment must be currently attached with shmaddr equal to the value returned by the attaching shmat() call.
  57.        On a successful shmdt() call, the system updates the members of the shmid_ds structure associated with the shared memory segment as  fol‐
  58.        lows:
  60.        • shm_dtime is set to the current time.
  62.        • shm_lpid is set to the process-ID of the calling process.
  64.        • shm_nattch is decremented by one.  If it becomes 0 and the segment is marked for deletion, the segment is deleted.
  66. RETURN VALUE
  67.        On success, shmat() returns the address of the attached shared memory segment; on error, (void *) -1 is returned, and errno is set to in‐
  68.        dicate the cause of the error.
  69.  
  70.        On success, shmdt() returns 0; on error -1 is returned, and errno is set to indicate the cause of the error.
  71.  
  72. ERRORS
  73.        When shmat() fails, errno is set to one of the following:
  75.        EACCES The calling process does not have the required permissions for the requested attach type, and does not have the CAP_IPC_OWNER  ca‐
  76.               pability in the user namespace that governs its IPC namespace.
  78.        EIDRM  shmid points to a removed identifier.
  80.        EINVAL Invalid  shmid  value,  unaligned (i.e., not page-aligned and SHM_RND was not specified) or invalid shmaddr value, or can't attach
  81.               segment at shmaddr, or SHM_REMAP was specified and shmaddr was NULL.
  83.        ENOMEM Could not allocate memory for the descriptor or for the page tables.
  85.        When shmdt() fails, errno is set as follows:
  87.        EINVAL There is no shared memory segment attached at shmaddr; or, shmaddr is not aligned on a page boundary.
  89. CONFORMING TO
  90.        POSIX.1-2001, POSIX.1-2008, SVr4.
  92.        In SVID 3 (or perhaps earlier), the type of the shmaddr argument was changed from char * into const void *,  and  the  returned  type  of
  93.        shmat() from char * into void *.
  95. NOTES
  96.        After a fork(2), the child inherits the attached shared memory segments.
  98.        After an execve(2), all attached shared memory segments are detached from the process.
  100.        Upon _exit(2), all attached shared memory segments are detached from the process.
  102.        Using  shmat()  with shmaddr equal to NULL is the preferred, portable way of attaching a shared memory segment.  Be aware that the shared
  103.        memory segment attached in this way may be attached at different addresses in different processes.  Therefore,  any  pointers  maintained
  104.        within the shared memory must be made relative (typically to the starting address of the segment), rather than absolute.
  106.        On Linux, it is possible to attach a shared memory segment even if it is already marked to be deleted.  However, POSIX.1 does not specify
  107.        this behavior and many other implementations do not support it.
  109.        The following system parameter affects shmat():
  111.        SHMLBA Segment low boundary address multiple.  When explicitly specifying an attach address in a call to shmat(), the caller  should  en‐
  112.               sure  that  the  address is a multiple of this value.  This is necessary on some architectures, in order either to ensure good CPU
  113.               cache performance or to ensure that different attaches of the same segment have consistent views within the CPU cache.  SHMLBA  is
  114.               normally some multiple of the system page size.  (On many Linux architectures, SHMLBA is the same as the system page size.)
  116.        The implementation places no intrinsic per-process limit on the number of shared memory segments (SHMSEG).
  118. EXAMPLES
  119.        The  two  programs  shown  below  exchange  a  string using a shared memory segment.  Further details about the programs are given below.
  120.        First, we show a shell session demonstrating their use.
  122.        In one terminal window, we run the "reader" program, which creates a System V shared memory segment and a System V  semaphore  set.   The
  123.        program prints out the IDs of the created objects, and then waits for the semaphore to change value.
  125.            $ ./svshm_string_read
  126.            shmid = 1114194; semid = 15
  128.        In  another terminal window, we run the "writer" program.  The "writer" program takes three command-line arguments: the IDs of the shared
  129.        memory segment and semaphore set created by the "reader", and a string.  It attaches the  existing  shared  memory  segment,  copies  the
  130.        string to the shared memory, and modifies the semaphore value.
  132.            $ ./svshm_string_write 1114194 15 'Hello, world'
  134.        Returning  to the terminal where the "reader" is running, we see that the program has ceased waiting on the semaphore and has printed the
  135.        string that was copied into the shared memory segment by the writer:
  137.            Hello, world
  139.    Program source: svshm_string.h
  140.        The following header file is included by the "reader" and "writer" programs.
  142.            #include <sys/types.h>
  143.            #include <sys/ipc.h>
  144.            #include <sys/shm.h>
  145.            #include <sys/sem.h>
  146.            #include <stdio.h>
  147.            #include <stdlib.h>
  148.            #include <string.h>
  150.            #define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
  151.                                    } while (0)
  152.  
  153.            union semun {                   /* Used in calls to semctl() */
  154.                int                 val;
  155.                struct semid_ds *   buf;
  156.                unsigned short *    array;
  157.            #if defined(__linux__)
  158.                struct seminfo *    __buf;
  159.            #endif
  160.            };
  161.  
  162.            #define MEM_SIZE 4096
  163.  
  164.    Program source: svshm_string_read.c
  165.        The "reader" program creates a shared memory segment and a semaphore set containing one semaphore.  It then attaches  the  shared  memory
  166.        object  into its address space and initializes the semaphore value to 1.  Finally, the program waits for the semaphore value to become 0,
  167.        and afterwards prints the string that has been copied into the shared memory segment by the "writer".
  168.  
  169.            /* svshm_string_read.c
  171.               Licensed under GNU General Public License v2 or later.
  172.            */
  173.            #include "svshm_string.h"
  174.  
  175.            int
  176.            main(int argc, char *argv[])
  177.            {
  178.                int semid, shmid;
  179.                union semun arg, dummy;
  180.                struct sembuf sop;
  181.                char *addr;
  182.  
  183.                /* Create shared memory and semaphore set containing one
  184.                   semaphore */
  185.  
  186.                shmid = shmget(IPC_PRIVATE, MEM_SIZE, IPC_CREAT | 0600);
  187.                if (shmid == -1)
  188.                    errExit("shmget");
  189.  
  190.                semid = semget(IPC_PRIVATE, 1, IPC_CREAT | 0600);
  191.                if (shmid == -1)
  192.                    errExit("shmget");
  193.  
  194.                /* Attach shared memory into our address space */
  195.  
  196.                addr = shmat(shmid, NULL, SHM_RDONLY);
  197.                if (addr == (void *) -1)
  198.                    errExit("shmat");
  199.  
  200.                /* Initialize semaphore 0 in set with value 1 */
  201.  
  202.                arg.val = 1;
  203.                if (semctl(semid, 0, SETVAL, arg) == -1)
  204.                    errExit("semctl");
  205.  
  206.                printf("shmid = %d; semid = %d\n", shmid, semid);
  207.  
  208.                /* Wait for semaphore value to become 0 */
  209.  
  210.                sop.sem_num = 0;
  211.                sop.sem_op = 0;
  212.                sop.sem_flg = 0;
  213.  
  214.                if (semop(semid, &sop, 1) == -1)
  215.                    errExit("semop");
  216.  
  217.                /* Print the string from shared memory */
  218.  
  219.                printf("%s\n", addr);
  220.  
  221.                /* Remove shared memory and semaphore set */
  222.  
  223.                if (shmctl(shmid, IPC_RMID, NULL) == -1)
  224.                    errExit("shmctl");
  225.                if (semctl(semid, 0, IPC_RMID, dummy) == -1)
  226.                    errExit("semctl");
  227.  
  228.                exit(EXIT_SUCCESS);
  229.            }
  230.  
  231.    Program source: svshm_string_write.c
  232.        The writer program takes three command-line arguments: the IDs of the shared memory segment and semaphore set that have already been cre‐
  233.        ated  by  the  "reader",  and  a string.  It attaches the shared memory segment into its address space, and then decrements the semaphore
  234.        value to 0 in order to inform the "reader" that it can now examine the contents of the shared memory.
  235.  
  236.            /* svshm_string_write.c
  238.               Licensed under GNU General Public License v2 or later.
  239.            */
  240.            #include "svshm_string.h"
  241.  
  242.            int
  243.            main(int argc, char *argv[])
  244.            {
  245.                int semid, shmid;
  246.                struct sembuf sop;
  247.                char *addr;
  248.                size_t len;
  249.  
  250.                if (argc != 4) {
  251.                    fprintf(stderr, "Usage: %s shmid semid string\n", argv[0]);
  252.                    exit(EXIT_FAILURE);
  253.                }
  254.  
  255.                len = strlen(argv[3]) + 1;  /* +1 to include trailing '\0' */
  256.                if (len > MEM_SIZE) {
  257.                    fprintf(stderr, "String is too big!\n");
  258.                    exit(EXIT_FAILURE);
  259.                }
  260.  
  261.                /* Get object IDs from command-line */
  262.  
  263.                shmid = atoi(argv[1]);
  264.                semid = atoi(argv[2]);
  265.  
  266.                /* Attach shared memory into our address space and copy string
  267.                   (including trailing null byte) into memory. */
  268.  
  269.                addr = shmat(shmid, NULL, 0);
  270.                if (addr == (void *) -1)
  271.                    errExit("shmat");
  272.  
  273.                memcpy(addr, argv[3], len);
  274.  
  275.                /* Decrement semaphore to 0 */
  276.  
  277.                sop.sem_num = 0;
  278.                sop.sem_op = -1;
  279.                sop.sem_flg = 0;
  280.  
  281.                if (semop(semid, &sop, 1) == -1)
  282.                    errExit("semop");
  283.  
  284.                exit(EXIT_SUCCESS);
  285.            }
  286.  
  287. SEE ALSO
  288.        brk(2), mmap(2), shmctl(2), shmget(2), capabilities(7), shm_overview(7), sysvipc(7)
  290. COLOPHON
  291.        This page is part of release 5.10 of the Linux man-pages project.  A description of the project, information about  reporting  bugs,  and
  292.        the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/.
  294. Linux                                                              2020-04-11                                                           SHMOP(2)

man shmat

  1. SHMOP(2)                                                    Linux Programmer's Manual                                                   SHMOP(2)
  3. NAME
  4.        shmat, shmdt - System V shared memory operations
  6. SYNOPSIS
  7.        #include <sys/types.h>
  8.        #include <sys/shm.h>
  10.        void *shmat(int shmid, const void *shmaddr, int shmflg);
  11.  
  12.        int shmdt(const void *shmaddr);
  13.  
  14. DESCRIPTION
  15.    shmat()
  16.        shmat()  attaches  the System V shared memory segment identified by shmid to the address space of the calling process.  The attaching ad‐
  17.        dress is specified by shmaddr with one of the following criteria:
  19.        • If shmaddr is NULL, the system chooses a suitable (unused) page-aligned address to attach the segment.
  21.        • If shmaddr isn't NULL and SHM_RND is specified in shmflg, the attach occurs at the address equal to shmaddr rounded down to the nearest
  22.          multiple of SHMLBA.
  24.        • Otherwise, shmaddr must be a page-aligned address at which the attach occurs.
  26.        In addition to SHM_RND, the following flags may be specified in the shmflg bit-mask argument:
  28.        SHM_EXEC (Linux-specific; since Linux 2.6.9)
  29.               Allow the contents of the segment to be executed.  The caller must have execute permission on the segment.
  31.        SHM_RDONLY
  32.               Attach  the  segment for read-only access.  The process must have read permission for the segment.  If this flag is not specified,
  33.               the segment is attached for read and write access, and the process must have read and write permission for the segment.  There  is
  34.               no notion of a write-only shared memory segment.
  36.        SHM_REMAP (Linux-specific)
  37.               This  flag specifies that the mapping of the segment should replace any existing mapping in the range starting at shmaddr and con‐
  38.               tinuing for the size of the segment.  (Normally, an EINVAL error would result if a mapping already exists in this address  range.)
  39.               In this case, shmaddr must not be NULL.
  41.        The  brk(2)  value of the calling process is not altered by the attach.  The segment will automatically be detached at process exit.  The
  42.        same segment may be attached as a read and as a read-write one, and more than once, in the process's address space.
  44.        A successful shmat() call updates the members of the shmid_ds structure (see shmctl(2)) associated with the shared memory segment as fol‐
  45.        lows:
  47.        • shm_atime is set to the current time.
  49.        • shm_lpid is set to the process-ID of the calling process.
  51.        • shm_nattch is incremented by one.
  53.    shmdt()
  54.        shmdt()  detaches  the  shared  memory segment located at the address specified by shmaddr from the address space of the calling process.
  55.        The to-be-detached segment must be currently attached with shmaddr equal to the value returned by the attaching shmat() call.
  57.        On a successful shmdt() call, the system updates the members of the shmid_ds structure associated with the shared memory segment as  fol‐
  58.        lows:
  60.        • shm_dtime is set to the current time.
  62.        • shm_lpid is set to the process-ID of the calling process.
  64.        • shm_nattch is decremented by one.  If it becomes 0 and the segment is marked for deletion, the segment is deleted.
  66. RETURN VALUE
  67.        On success, shmat() returns the address of the attached shared memory segment; on error, (void *) -1 is returned, and errno is set to in‐
  68.        dicate the cause of the error.
  69.  
  70.        On success, shmdt() returns 0; on error -1 is returned, and errno is set to indicate the cause of the error.
  71.  
  72. ERRORS
  73.        When shmat() fails, errno is set to one of the following:
  75.        EACCES The calling process does not have the required permissions for the requested attach type, and does not have the CAP_IPC_OWNER  ca‐
  76.               pability in the user namespace that governs its IPC namespace.
  78.        EIDRM  shmid points to a removed identifier.
  80.        EINVAL Invalid  shmid  value,  unaligned (i.e., not page-aligned and SHM_RND was not specified) or invalid shmaddr value, or can't attach
  81.               segment at shmaddr, or SHM_REMAP was specified and shmaddr was NULL.
  83.        ENOMEM Could not allocate memory for the descriptor or for the page tables.
  85.        When shmdt() fails, errno is set as follows:
  87.        EINVAL There is no shared memory segment attached at shmaddr; or, shmaddr is not aligned on a page boundary.
  89. CONFORMING TO
  90.        POSIX.1-2001, POSIX.1-2008, SVr4.
  92.        In SVID 3 (or perhaps earlier), the type of the shmaddr argument was changed from char * into const void *,  and  the  returned  type  of
  93.        shmat() from char * into void *.
  95. NOTES
  96.        After a fork(2), the child inherits the attached shared memory segments.
  98.        After an execve(2), all attached shared memory segments are detached from the process.
  100.        Upon _exit(2), all attached shared memory segments are detached from the process.
  102.        Using  shmat()  with shmaddr equal to NULL is the preferred, portable way of attaching a shared memory segment.  Be aware that the shared
  103.        memory segment attached in this way may be attached at different addresses in different processes.  Therefore,  any  pointers  maintained
  104.        within the shared memory must be made relative (typically to the starting address of the segment), rather than absolute.
  106.        On Linux, it is possible to attach a shared memory segment even if it is already marked to be deleted.  However, POSIX.1 does not specify
  107.        this behavior and many other implementations do not support it.
  109.        The following system parameter affects shmat():
  111.        SHMLBA Segment low boundary address multiple.  When explicitly specifying an attach address in a call to shmat(), the caller  should  en‐
  112.               sure  that  the  address is a multiple of this value.  This is necessary on some architectures, in order either to ensure good CPU
  113.               cache performance or to ensure that different attaches of the same segment have consistent views within the CPU cache.  SHMLBA  is
  114.               normally some multiple of the system page size.  (On many Linux architectures, SHMLBA is the same as the system page size.)
  116.        The implementation places no intrinsic per-process limit on the number of shared memory segments (SHMSEG).
  118. EXAMPLES
  119.        The  two  programs  shown  below  exchange  a  string using a shared memory segment.  Further details about the programs are given below.
  120.        First, we show a shell session demonstrating their use.
  122.        In one terminal window, we run the "reader" program, which creates a System V shared memory segment and a System V  semaphore  set.   The
  123.        program prints out the IDs of the created objects, and then waits for the semaphore to change value.
  125.            $ ./svshm_string_read
  126.            shmid = 1114194; semid = 15
  128.        In  another terminal window, we run the "writer" program.  The "writer" program takes three command-line arguments: the IDs of the shared
  129.        memory segment and semaphore set created by the "reader", and a string.  It attaches the  existing  shared  memory  segment,  copies  the
  130.        string to the shared memory, and modifies the semaphore value.
  132.            $ ./svshm_string_write 1114194 15 'Hello, world'
  134.        Returning  to the terminal where the "reader" is running, we see that the program has ceased waiting on the semaphore and has printed the
  135.        string that was copied into the shared memory segment by the writer:
  137.            Hello, world
  139.    Program source: svshm_string.h
  140.        The following header file is included by the "reader" and "writer" programs.
  142.            #include <sys/types.h>
  143.            #include <sys/ipc.h>
  144.            #include <sys/shm.h>
  145.            #include <sys/sem.h>
  146.            #include <stdio.h>
  147.            #include <stdlib.h>
  148.            #include <string.h>
  150.            #define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
  151.                                    } while (0)
  152.  
  153.            union semun {                   /* Used in calls to semctl() */
  154.                int                 val;
  155.                struct semid_ds *   buf;
  156.                unsigned short *    array;
  157.            #if defined(__linux__)
  158.                struct seminfo *    __buf;
  159.            #endif
  160.            };
  161.  
  162.            #define MEM_SIZE 4096
  163.  
  164.    Program source: svshm_string_read.c
  165.        The "reader" program creates a shared memory segment and a semaphore set containing one semaphore.  It then attaches  the  shared  memory
  166.        object  into its address space and initializes the semaphore value to 1.  Finally, the program waits for the semaphore value to become 0,
  167.        and afterwards prints the string that has been copied into the shared memory segment by the "writer".
  168.  
  169.            /* svshm_string_read.c
  171.               Licensed under GNU General Public License v2 or later.
  172.            */
  173.            #include "svshm_string.h"
  174.  
  175.            int
  176.            main(int argc, char *argv[])
  177.            {
  178.                int semid, shmid;
  179.                union semun arg, dummy;
  180.                struct sembuf sop;
  181.                char *addr;
  182.  
  183.                /* Create shared memory and semaphore set containing one
  184.                   semaphore */
  185.  
  186.                shmid = shmget(IPC_PRIVATE, MEM_SIZE, IPC_CREAT | 0600);
  187.                if (shmid == -1)
  188.                    errExit("shmget");
  189.  
  190.                semid = semget(IPC_PRIVATE, 1, IPC_CREAT | 0600);
  191.                if (shmid == -1)
  192.                    errExit("shmget");
  193.  
  194.                /* Attach shared memory into our address space */
  195.  
  196.                addr = shmat(shmid, NULL, SHM_RDONLY);
  197.                if (addr == (void *) -1)
  198.                    errExit("shmat");
  199.  
  200.                /* Initialize semaphore 0 in set with value 1 */
  201.  
  202.                arg.val = 1;
  203.                if (semctl(semid, 0, SETVAL, arg) == -1)
  204.                    errExit("semctl");
  205.  
  206.                printf("shmid = %d; semid = %d\n", shmid, semid);
  207.  
  208.                /* Wait for semaphore value to become 0 */
  209.  
  210.                sop.sem_num = 0;
  211.                sop.sem_op = 0;
  212.                sop.sem_flg = 0;
  213.  
  214.                if (semop(semid, &sop, 1) == -1)
  215.                    errExit("semop");
  216.  
  217.                /* Print the string from shared memory */
  218.  
  219.                printf("%s\n", addr);
  220.  
  221.                /* Remove shared memory and semaphore set */
  222.  
  223.                if (shmctl(shmid, IPC_RMID, NULL) == -1)
  224.                    errExit("shmctl");
  225.                if (semctl(semid, 0, IPC_RMID, dummy) == -1)
  226.                    errExit("semctl");
  227.  
  228.                exit(EXIT_SUCCESS);
  229.            }
  230.  
  231.    Program source: svshm_string_write.c
  232.        The writer program takes three command-line arguments: the IDs of the shared memory segment and semaphore set that have already been cre‐
  233.        ated  by  the  "reader",  and  a string.  It attaches the shared memory segment into its address space, and then decrements the semaphore
  234.        value to 0 in order to inform the "reader" that it can now examine the contents of the shared memory.
  235.  
  236.            /* svshm_string_write.c
  238.               Licensed under GNU General Public License v2 or later.
  239.            */
  240.            #include "svshm_string.h"
  241.  
  242.            int
  243.            main(int argc, char *argv[])
  244.            {
  245.                int semid, shmid;
  246.                struct sembuf sop;
  247.                char *addr;
  248.                size_t len;
  249.  
  250.                if (argc != 4) {
  251.                    fprintf(stderr, "Usage: %s shmid semid string\n", argv[0]);
  252.                    exit(EXIT_FAILURE);
  253.                }
  254.  
  255.                len = strlen(argv[3]) + 1;  /* +1 to include trailing '\0' */
  256.                if (len > MEM_SIZE) {
  257.                    fprintf(stderr, "String is too big!\n");
  258.                    exit(EXIT_FAILURE);
  259.                }
  260.  
  261.                /* Get object IDs from command-line */
  262.  
  263.                shmid = atoi(argv[1]);
  264.                semid = atoi(argv[2]);
  265.  
  266.                /* Attach shared memory into our address space and copy string
  267.                   (including trailing null byte) into memory. */
  268.  
  269.                addr = shmat(shmid, NULL, 0);
  270.                if (addr == (void *) -1)
  271.                    errExit("shmat");
  272.  
  273.                memcpy(addr, argv[3], len);
  274.  
  275.                /* Decrement semaphore to 0 */
  276.  
  277.                sop.sem_num = 0;
  278.                sop.sem_op = -1;
  279.                sop.sem_flg = 0;
  280.  
  281.                if (semop(semid, &sop, 1) == -1)
  282.                    errExit("semop");
  283.  
  284.                exit(EXIT_SUCCESS);
  285.            }
  286.  
  287. SEE ALSO
  288.        brk(2), mmap(2), shmctl(2), shmget(2), capabilities(7), shm_overview(7), sysvipc(7)
  290. COLOPHON
  291.        This page is part of release 5.10 of the Linux man-pages project.  A description of the project, information about  reporting  bugs,  and
  292.        the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/.
  294. Linux                                                              2020-04-11                                                           SHMOP(2)

 共享内存示例 12.1c

  1. #include <stdio.h>
  2. #include <sys/ipc.h>
  3. #include <sys/shm.h>
  4. #include <sys/types.h>
  5. #include <unistd.h>
  6. #include <string.h>
  7. #include <sys/wait.h>
  8.  
  9. char msg[] = "Hello world";
  10.  
  11. int main(void)
  12. {
  13. 	int shmid;
  14. 	pid_t pid;
  15.  
  16. 	shmid = shmget(IPC_PRIVATE, 1024, IPC_CREAT);
  17.  
  18. 	pid = fork();
  19.  
  20. 	if(pid > 0)
  21. 	{
  22. 		char *p_addr;
  23. 		p_addr = shmat(shmid, NULL, 0);
  24.  
  25. 		memset(p_addr, '\0', sizeof(msg));
  26. 		memcpy(p_addr, msg, sizeof(msg));
  27.  
  28. 		shmdt(p_addr);
  29.  
  30. 		waitpid(pid, NULL, 0);
  31. 	}
  32. 	else if(pid == 0)
  33. 	{
  34. 		char *c_addr;
  35. 		c_addr = shmat(shmid, NULL, 0);
  36.  
  37. 		printf("Child process waits a short time: \n");
  38. 		sleep(3);
  39. 		printf("Child Process reads from shared memory: %s\n", c_addr);
  40. 		shmdt(c_addr);
  41. 	}
  42. 	else
  43. 		perror("fork");
  44.  
  45. 	return 0;
  46. }

 

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号