Lecture 14

March 12, 2019

For today:

1) Read the Little Book of Semaphores, Chapters 1 and 2, and download Sync (see below)

2) Start Homework 6

3) Turn in a project update (see the assignment on Canvas)

Today:

1) Homework 6

2) Introduction to concurrency

For next time:

1) Read HFC Chapter 7

2) Finish Homework 6

3) Plan the end game of your project, report due March 26

End of project checklist

1) Is your Trello board up to date?  Has every member of the team participated by creating and moving cards?  If not, explain.

2) Looking at the history of commits in your repo, has every member of the team made a substantial contribution?  If not, explain.

3) Review the Project 1 report assignment so you know what should be in the report.

4) Decide who will do what between now and the deadline.  Choose one person to make a final pass through the report, spell check it, and submit the URL.

Homework 6 suggestions

Suggestions for working with code like this:

1) Draw diagrams!

2) Use gdb and/or print statements to compare your diagrams with reality.

3) If you find yourself doing random-walk programming, stop!

4) Type checking is your friend.

5) Use well-named variables to help you keep it all straight.

The * operator means three different things, depending on where it appears:

1) In a variable declaration, it specifies a type, like Node* or Node**.

2) On the right side of an assignment, it indicates a value.

3) On the left side of an assignment, it indicates a location (aka "target").

For example, 

Node *current;

current = *list;

means, 

1) Create a variable named current that has type Node*.  That's usage 1.

2) Follow list (which is a Node**) to its pointee (which is a Node*).  Get that value (that's usage 2) and assign it to current (that's not usage 3, because we are not dereferencing current).

You can write the same code like this:

Node *current = *list;

This line can be confusing because it looks like we are dereferencing current on the left, but we are not.

Exercises

1) In ExercisesInC, pull from upstream to get good_list.c and bad_list.c which are in exercises/ex06.

2) In a browser, load C Tutor.  Paste in the code from  good_list.c and step through the execution.

CTutor can be useful to check your understanding, but it comes with a few caveats:

• • The visualizer has a bit of trouble disambiguating arrays and structs. Pointers to structs appear to point to the first element of the struct, rather than the struct itself as they should.

  • If you have memory leaks in your program, they may not be evident in the visualization. Use valgrind instead, or better yet be disciplined about how you allocate and free memory.

  • The visualizer for C is somewhat experimental/unstable, and won't work for big programs.

Just like any tool this is not a replacement for your understanding. You need to know enough to tell when your tools are lying to you!

3) What does the following function do?  First draw a stack diagram of its execution, then use CTutor to check your understanding.

void mystery(Node **list) {

    Node *head = *list;

    *list = head->next;

}

GDB

gdb is a bare-bones tool for debugging C.

1) In exercises/ex06, compile run bad_list.c like this

gcc -g -Wall bad_list.c

The -g flag tells gcc to include debugging information in the executable.

2) Run a.out; it should cause a segmentation fault.

3) Start the debugger from the command line like this

$ gdb a.out

At the gdb prompt, type

(gdb) run

You should still get a segfault, but this time gdb will show you the line of code where it happened.

At the gdb prompt, you can print the values of variables, list the code, step through the program, set break points, and resume the execution of the program.

You can even change the values of variables and resume the program, but I don't recommend it.

This gdb tutorial is a good place to learn more.

Semaphores

To install and run Sync.py:

git clone https://github.com/AllenDowney/LittleBookOfSemaphores

cd LittleBookOfSemaphores/code

python Sync.py sync_code/signal.py