peterson's solution for critical section problem

Question

#include<stdio.h>
#include<sys/types.h>
#include<stdlib.h>
int turn;
int flag[2];
int main(void)
{
        int pid,parent=1;
        printf("before vfork\n");
        if((pid=vfork())<0)
        {
                perror("vfork error\n");
                return 1;

        }
        while(1)
        {
                if(pid==0)
                {
                     while(parent==1)
                     {
                      sleep(2);
                     }
                     parent=0;
                     flag[0]=1;
                     turn=1;
                     while(flag[1]&&turn==1);
                     printf("This is critical section:parent process\n");
                     flag[0]=0;
                }
                else
                {
                        parent=2;
                        printf("This is parent");
                        flag[1]=1;
                        turn=0;
                        while(flag[0]&&turn==0);
                        printf("This is critical section:child process %d \n",pid);
                        flag[1]=0;
                }
        }

}

This is my code. Can anyone tell why control is not coming to my parent process.

Answer 1

This code doesn't guarantee fairness; it only prevents deadlock.

There's nothing stopping the child process from executing over and over again.

If you want the lock to be fair, you'll have to make it so.

Answer 2

Because, the entire virtual address space of the parent is replicated in the child. So two processes has separate address spaces. And flag[1] never become 1 in parent process.

Answer 3

man 2 vfork says:

   (From  POSIX.1)  The  vfork()  function has the same effect as fork(2),
   except that the behavior is undefined if the process created by vfork()
   either  modifies  any  data other than a variable of type pid_t used to
   store the return value from vfork(), or returns from  the  function  in
   which  vfork()  was called, or calls any other function before success-
   fully calling _exit(2) or one of the exec(3) family of functions.

Because you are modifying data in child process, vfork() behaviour is undefined, so whatever it does is correct (here by "correct" I mean "complies with the spec").

Answer 4

vfork() was designed for fast creation of processes with execve(): vfork() + immediate execve(). And in cases when children modifies any data of parent process, behavior is undefined. Check man about details.

In my case, that behavior was such that parent reach control only after close of children.

Answer 5

Here is the important bit from the Linux man page. Keywords: "parent is suspended until the child ..."

    vfork()  differs from fork(2) in that the parent is suspended until the
    child makes a call to execve(2) or _exit(2).  The child shares all mem-
    ory  with its parent, including the stack, until execve(2) is issued by
    the child.  The child must not return from the current function or call
    exit(3), but may call _exit(2).

Your parent process has been suspended. Consider using clone.