Reference no: EM133569861

Deep-dive into Data Race

Description:

In this assignment, you will use GDB in cse-linux-01.unl.edu to control execution of a racy multithreaded program. (Note that you must do your work in cse-linux-01.unl.edu.) To see the racy result, compile the program below and run it

Your task is to use GDB to control the execution of this program so that at the end (after all threads have completed their executions), you see the following statement: sharedCounter = 0 before the main thread exits. To accomplish this goal, you control the execution of each thread so that they cannot interfere with each other. In other words, you will use GDB to serialize the execution of all threads (yes, this means no parallelism, so no race). This is the command you need to use GDB:

Requirements:

so, open the file and replace "Firstname" and "Lastname" with your name.
2. Allow the main thread to create all threads prior to execution. This means that you must ensure that once a thread is created, it is suspended at a safe point (hint: set a break point where you determine to be a safe point to suspend) until the remaining threads have been created. Simply creating a thread and then letting it run to completion is not a valid solution. At the end of this step, you should see the following information in your GDB console (you can ignore the LWP numbers, yours would be different than the figure):

3. Once all threads have been created, control the execution within the bodies of MyCounterPlus and MyCounterMinus. You can let the loop body run through without stopping during the entire increment or decrement operation. However, you need to stop each thread before it terminates. After each thread runs and suspends, you need to issue "print sharedCounter" command. For example, you should see the following information in your gdb console after thread 2 finishes:

and the following information after thread 3 finishes:
Keep repeating this step until all threads have finished executing the loop bodies. The
sharedCounter values should oscillate between 2000000 and 0.

4. Next, issue the "info threads" and "print sharedCounter" commands. You should see the following information:

Note that all threads are still alive and threads 2-9 have finished their tasks; sharedCounter is 0.

5. Next, terminate each thread starting from thread 2 (DO NOT TERMINATE thread 1!). After each 3

Note that only thread 1 and threads 5 - 9 are still alive.

6. After threads 2 - 9 have been terminated, issue the "info threads" command. You should see the following screen:

That is, only thread 1 is still alive.

7. Next, you need to terminate thread 1. First, issue the command "print myName" then continue to exit the program. We require that your debugging session exits gracefully. That is, you should be able to quit GDB and return to the linux command prompt. If you cannot, you will lose points. When you are successful, you should see the following screen (note that "Firstname Lastname" should be your name):

Useful GDB Commands:

You can use any GDB command to accomplish this task. However, the list below contains the most relevant commands that should allow you to complete this task.
break (b) # set a breakpoint
delete <bp> (d 1) # delete a breakpoint or all breakpoints if no bp is specified run (r)
continue (c) # continue to run next (n) # stepping through
thread apply <thread_ID> <command> (e.g., thread apply 1 c) # send "continue" to thread 1 only thread <thread_ID> (e.g., thread 1) # set thread 1 as the active thread

set scheduler-locking on # prevent your scheduler from having a mind of its own
set scheduler-locking off # give the scheduling control back

print <variable> (e.g., print sharedCounter) # to periodically check if races already occur. info break # see all break points
info threads # see the status of all threads

What should I do if my GDB console hangs?
If your program should hang, try to hit control-C to terminate the hung thread. If this works, you can continue to debug without restarting gdb. However, if that does not work, you have a deadlock. The easiest way to kill the deadlocked gdb process is to log-in to cse-linux-01.unl.edu using a different terminal. Issue (prompt> ps aux | grep username). It will list all the processes running under your username. Find the one called gdb command=username.script threadRace and look for its PID. You can then issue (command prompt> kill -9 PID) to kill that process. Do not leave any hung processes in the system. Our system administrator will not be happy and trust me, you will hear from them.

Submission:
You need to submit three files via canvas. Each is described below:

1. my_lastname.script (e.g. if your last name is Doe then the file is named doe.script) - this file contains your automated action to generate the output file (described next) and any other tasks that you can predictably and repeatedly perform (e.g., setting break points). Not all tasks have to be automated but you should try to automate as much as you can. Because we are debugging a multithreaded program, the execution order may not be deterministic so some actions have to be
manually issued from the console. However, one requirement is that you must have the following commands at the beginning of my_lastname.script. These commands ensure that your debugging session produces an output log that you will need to submit.
set pagination off

set logging file my_lastname.output

set logging on

2. my_lastname.output (e.g., to follow the above example, this file should be named doe.output) - this file logs all your command and output from the GDB console. It should have all the commands that you use to control the execution of these threads and the output due to each command. In a nutshell, this file encapsulates your debugging process. Note that you must record the output of a debugging session in this file. If your output file contains information from multiple debugging sessions, you will lose points.

3. my_lastname.report - answer the following questions in this file:
Why do we need to issue a gdb command "set scheduler-locking on" in the script file? What exactly does the command do (do not answer "proven your scheduler from having a mind of its own")?

How many hours did you spend on this assignment?
What is the most challenging component of this assignment?
How does this assignment help you understand the concepts of data race and thread synchronization?
On the scale of 1 to 5 (5 is the most challenging), rate the level of easiness for this assignment. How would you improve this assignment? Please provide at least three points.

Attachment:- Deep-dive into Data Race.rar