ISU - Exercise 11 - IPC

Goal:

The goal of this exercise is to get familiar with fork(),  _exit() and wait() and get an understanding of inter-process communication. Know what a child inherent from its parent and what shared memory is used for.

Exercise 1.1: Simple process creation

Our program:

Output:

Explain the value of the PIDs and the return values from fork() - how can one function return
two different values?
The child will return 0 on fork() and the parent will return the real pid of the child. When fork() is being executed a new process is being created which means the int pid will exist both in the parent and in the child and contain two different values will have been assigned.


Explain what happens when a process is forked:
What happens to the memory from the parent passed to the child?
The child gets a complete virtual copy but only if the child writes to the memory will it phsycally get its own. This is to ensure if you clone a progress that takes up ex 1GB of memory there is no need to physically require 2GB's unless the child needs to manipulate it.
What is passed to the child process and what is not?
The child does not get mutexes or semaphore locks. It also doesn't inherent any timers.
See this source for more.
Why must it be _exit() that is called from within the child and not exit()?
You risk flushing stdio buffers twice and remove temporary files. In additional destructors might be called incorrectly.

Exercise 1.2: Single program - multiple processes

Our program:

Output:

Explain what happens when a process is spawned via the exec() function familily:
What is passed to the "child" process and what is not?

exec() will replace the current process image with a completely new program. Essentially killing the old and creating a new but keeping the same PID. Open file descripters will still stay open


What should one be vary about when spawning processes in a security context (in relation
to the previous question)?
Files are kept open and are therefor exposed. What if we left the password file open?

Exercise 2: Shared memory

Questions to answer:

Describe the concept behind shared memory this includes which steps to go through and

what to remember from a purely functional point of view.

The reason to use shared memory is to allow for an abitrary amount of processes which have access to a certain section of memory, known as shared memory. From  the previous exercise we know each process has its own memory space but using shared memory we can easily and quickly communicate between processes.

You have to open the memory object and set its size, then you map that to the process' virtual memory. The functions are respectively shm_open(), ftruncate() and mmap().

When you have used the memory you must free it by using the above mentioned functions counterparts munmap(), close() and shm_unlink().

Under which circumstances would you consider shared memory a viable solution?

In highspees applications with multiple processes. If you only have one process this would be stupid.

Consider a scenario where two programs communicate via shared memory and program

B has taken a mutex that program A also waits for. In this unfortunate moment program

B crash whilst having acquired said mutex.

What is the problem?

The mutex will obvsiouly never be released and therefor the entire program will hault. Also known as Starvation.

How would you resolve it? (See pthread ROBUST - Google it)

Using pthread_mutex_robust you can tell the process which is waiting on the mutex that the process holding the mutex has crashed.  This makes the program able to continue but causes some problems descriped in the next question

But using said approach what does this mean for what I may do in the critical section

part, namely the part where I have acquired the mutex?

When a process crash while holding the mutex the mutex will become inconsistent. When a mutex is inconsistent is it not protected which means it can't be locked. The next process to acquire the mutex from the crashed process will have to call pthread_mutex_consisten().

Where is your code?

Unfortunately we couldn't get our code working but we try to prove we understand the theory by answering the questions anyway.