May 3, 2019
For today:
1) Finish Homework 12, which is Exercise 13
2) Read The Little Book of Semaphores, Chapter 3, up through Section 3.6
Today:
1) Exercise 13 solution
2) Sync with Semaphores
3) Project check in
For next time:
1) Fill out this end of semester survey (ideally in class today)
2) Turn in your Project 2 Report
3) Prepare a short (!) Project 2 Presentation
Our final event period is Thursday 9 May in AC326 at 4pm.
1) From Canvas, download word_count_soln.c and list_error_soln.c
https://canvas.instructure.com/files/76972852/download?download_frd=1
https://canvas.instructure.com/courses/1498390/files?preview=76972851
2) Compare word_count.c and word_count_soln.c, which demonstrates one pattern, simplifying complex structures by making copies.
By the way, if you don't already use meld, add it to your toolkit!
3) Compare list_errors.c and list_errors_soln.c, which demonstrates another pattern, deallocating complex structures using a set of pointers "to be freed".
This pattern is similar to the "mark and sweep" method of garbage collection.
Memory management is hard, so the best solution is to avoid it:
1) If possible, use a language with garbage collection!
2) For short-running processes, it's probably best to avoid freeing anything.
However, for long-running processes in C, here are some "safer" options for managing memory:
1) Avoid dynamic allocation. Use static and stack allocation.
This is what many kernels do. The drawback is that it often imposes resource limits. And it clashes with object-oriented style.
2) Avoid sharing. Make all data structures tree-shaped, so there is only one pointer to each allocated chunk. Write destructors for all dynamically allocated types.
The drawback is that it wastes time and space making copies.
3) Use region-based memory management. This is particularly suitable if the computation works in phases, or units of work (like server requests).
4) Fork short-lived processes. Also suitable for servers.
5) Use libraries with garbage collection (although these seem to be perpetually not ready for prime time).
6) Not recommended: Do careful analysis of all functions that allocate or deallocate data structures, and document their interfaces in exacting detail.
Garbage collection with deadlines
One of the reasons C and C++ are still used for robotics and other environments with real-time constraints is that people in those fields have inherited an atavistic dread of garbage collection.
These fears are mostly obsolete, as most modern GCs are incremental.
I would rather take a working program and tune its GC behavior than take a broken program and fix its memory management.
Let's solve the reader-writers problem with mutex and condition variables.
1) Read the solution using Semaphores in Section 4.2 of LBoS, page 65
2) Run the solution in Sync. Clone the LBoS repo, if you have not already:
git clone https://github.com/AllenDowney/LittleBookOfSemaphores
Then
cd LittleBookOfSemaphores/code
python Sync.py sync_code/readwrite.py
Run the solution in Sync until you feel like you understand it.
3) Then
cd ExercisesInC/exercises/ex12
Compile and run read_write.c.
4) Modify reader_code and writer_code to enforce the constraints of the Reader-Writer problem. Notice that the program already includes a mutex and condition variable.
First, read this parody of a book report.
What are the tropes of student writing that this article is making fun of?
1) The title.
2) It's a personal narrative.
3) The author seems like some combination of a hostage making an involuntary statement and a puppet expressing other people's words and ideas.
4) It reads like responses to a list of questions the reader does not see.
5) It brags about things the reader does not find impressive.
Fundamentally, this kind of writing fails because it does not address a real audience. It addresses the fake audience of "the teacher forcing me to answer a list of questions".
Which is, I concede, an element of many assignments, including the reports in this class.
But please remember that your reports have a real audience and a real goal.
1) Future students interested in doing something similar.
We installed OpenGL and it was really hard -> write the tutorial you didn't find
We tried a bunch of libraries and we chose x -> which ones, what were the problems, WHY did you choose the ones you chose?
2) Potential employers who want to know what you can do.
Complaining about your travails does not impress
So, as you turn to the second report:
1) Give it a reader-centric title (and put your names on it)
2) Write as if the project is complete, mostly past and present tense.
3) Remove the learning goals and add a reflection. Maybe don't talk about MVP?
4) Most of all, write like an autonomous person addressing an audience in order to achieve a goal.
Formatting
Check the capitalization of everything! C, Python, OpenGL, etc. Getting it wrong is unprofessional. Being inconsistent is even worse.
Use MarkDown formatting to make the document look professional (smaller headings?).
Include code as formatted text, not images.
If you include images, double check that they render correctly on GitHub.
Consider using GitHub Pages for a better looking report. But please use a theme with a light background.