Understanding through visual representation

115 views 11:24 am 0 Comments June 27, 2023

Lab 9 (Week 12)

UNIX Concurrent I/O

Purpose

After completing the exercises in this week (Lab 9), You will gain a better understanding through visual representation of:

Basic file I/O commands such as open(), close(), read(), and write(),

Concurrent I/O between parent and child processes,

The importance of not relying on scheduling behavior for depending upon output order.

Prerequisites

In this lab, you will explore a simulation software (created by Steve Robbins) named “UNIX Concurrent I/O simulator”.

Although this simulator is titled UNIX Concurrent I/O, no significant experience with UNIX I/O is necessary to understand this simulator. Rather, you should be comfortable with the basic UNIX functions: open(), read(), write(), and close() system calls, as well as the fork() function for creating new processes.

The fork() system call for process creation is covered in detail in Chapter 3. It is important to remind yourself the return value of fork() — the child process is returned the value of zero, a value > 0 is returned to the parent. (Assuming no errors occur during process creation.)

It is also important to understand that after completing fork(), both the parent and child processes share the same set of open files and that any I/O done by one process will be seen by the other (i.e. I/O performed by the parent process will be visible to the child).

However, it is important where the  open() call is done relative to the fork(): if open() is performed before fork(), the open file is visible to both processes; if open() is performed after fork(), both the parent and child open different files.


In addition, it will be useful you skim through Section 10.4.3 and Figure 10.9 in the textbook to get a basic understanding of inodes. In UNIX an inode is how files are represented. Inodes are numbered; references to the same inode indicate references to the same file.

Starting the Simulator

Download the UNIX Concurrent I/O simulator (io.zip) from LearnJCU and extract the zip file. This produces a folder named io.

The user manual for this simulator, io_doc.html, is included in this folder. It is strongly suggested that you read through this documentation describing how the simulator operates prior to beginning the following exercises.

Exercise Tasks

Perform the following steps using the concurrent I/O simulator

In the io directory you will find the file ioconfig. This is the configuration file for the concurrent I/O simulator. Add a line at the top of this file that begins with user followed by your name. For example, if your name is Avi Galvin, you would enter the following:

user Avi Galvin

Save and close the configuration file. This will ensure any log files you generate will have your name at the top.

In the io directory, execute runio(UNIX, Linux, Mac OS X) or runio.bat (Windows.) This will start the concurrent I/O simulator.

Click the button labeled Open Log in the left-hand column of the UNIX Concurrent IO Simulation window. After you have pushed this button, its name will change to Close Log.

Click on the button labeled Run in the right-hand column of the main window. This will run the first program of the simulator which forks a child process.

After the simulator runs this program, click the button Log Image in the left-hand column of the main window.

Click the pink button labeled Reset in the right-hand column of the main window.

Next, click the button labeled Step at the top of the right-hand column of the main window. The Step button executes the line of code pointed to by the red arrow in the program. Click this button several times so that both the parent and child processes complete execution.

Reset the simulator once again.

At the top of the middle column of the main window is a button which begins with the label After Fork: The default value of this button should be parent. Click this button so that it changes to After Fork: child. The value of this button determines whether the parent or child process runs first after the call to fork(). Run the program again.

Click the pink button labeled Choose Program in the lower right-hand corner of the main window, opening a pop-up window that allows you to choose from a list of programs the simulator may execute. Choose Program2 from this list.

Run the program again, and then log the image.

Click the button labeled After Fork: to reset its value to parent. Reset the program, and then run it again. After this program has run, log the image.

Choose Program3.

Run the program again, and then log the image.

Reset, then run, the program. After this program has completed, log the image.

Choose Program4.

Run the program, and then log the image.

Resent the program and experiment with this program by altering whether the parent or child process runs after the fork.

Close the log file by clicking on the Close Log button. You have created a file called logfile01.html in the logs directory within the io directory.

Click the pink Quit button in the upper left-hand corner of the main window to terminate the simulator.

Submit your log file — logfile01.html — to your instructor per his or her instructions.

———————————————————————————————–

Questions

Answer the following questions after completing Steps 1-21 above.

After completing Step 4, which process ran first?

a) Parent process
b) Child process

After completing Step 4, what is the value of buf for both the parent and child processes?

a) ab
b) cd
c) abcd
d) cdab

After completing Step 7, which of the following statements best explains the final value of buf?

Since the parent and child are the same program, we can expect the same output

Since the open() system call is done after fork(), the parent and child each open separate copies of the same file

Since the open() system call is done after fork(), the parent and child each open separate copies of a different file.

None of the above

After completing Step 9, does the process which runs first affect the final value of buf for both the parent and child processes?

a) Yes
b) No

After completing Step 11, notice the final value of buf for the parent and child processes is different? Which of the following statements best explains why it is different?

The parent and child programs are the same — the different output makes no sense.

Because the open() system call is done before fork(), the parent and child processes are sharing the same file descriptor and are sequentially reading from the same file.

Because the open() system call is done before fork(), the parent and child processes each open separate copies of the same file.

Because the open() system call is done before fork(), the parent and child processes each open separate copies of a different file.

After completing Step 12, does the process which runs first affect the final value of buf for both the parent and child processes?

a) Yes
b) No

After completing Step 14, what is the final value of outfile? (It appears on the right-hand side of the main window under Disk Space.)

a) abcd
b) ABcd
c) abCD
d) ABCD

After completing Step 14, which of the following statements best explains the final value of the file outfile?

Both the parent and child processes open the same file with the same inode, although each process writes different values to the file.

Both the parent and child processes open different files with the same inode; the process that finishes last determines the final value of outfile.

Both the parent and child processes open the same file with the same name but different inodes; the process that finishes last determines the final value of outfile.

Since the open() system call is done after fork(), the parent and child processes each open a copy of the same file.

After completing Step 15, does the process which runs last affect the final value of the file outfile?

a) Yes
b) No

After completing Step 18, does the order of which process runs first affect the final value of the file outfile?

a) Yes
b) No

After completing Step 18, which of the following statements best explains the final value of the file outfile?

The parent and child programs are the same — the different output makes no sense.

Since the open() system call is done before fork(), the parent and child processes share the same file descriptor and are sequentially writing to the same file.

Since the open() system call is done before fork(), the parent and child processes each open separate copies of the same file.

Since the open() system call is done before fork(), the parent and child processes each open separate copies of a file with the same name, but different inode values.

The button with the label Active: in the right-hand column can be used to determine which process is running. Using this button, run Program4 such that the value of outfile is abABcdCD. What is the necessary order of execution (indicated by process number) to generate this output? (You will have to use the Step button which will allow you to step through the program line-by-line.)

a) 1001, 1002, 1001, 1002
b) 1002, 1001, 1002, 1001
c) 1001, 1001. 1002, 1002
d) 1002, 1002, 1001, 1001

——————————————————————————————-

Assessment

1%

~ This is the End of Lab 9 ~

Tags: , , , , , , , , , ,