Recap of CSE 451 Project 0 and Introduction to Project 1

1. Section #3 CSE 451 Project 0 recap and some Proj 1 stuff

2. Homework Mostly very good Feel free to quote the book, it shows you’ve read it For the major activities, there were five and three point lists in the sections “Process Management” and “Memory Management” (but I was lenient about that this time)

3. Project 0 Grading Scale • Part 1 out of 10 points • 2 points each for each bug • 3 points for sort, 3 for reverse • Part 2 out of 10 points • 0-4 points if you didn’t turn it in or it was completely broken or unfinished • 5-7 points if things were mostly working but had major problems • 8-9 points if minor problems • 10 points: No obvious bugs AND clean neat code • Grades will be posted today on MyUW via Catalyst

4. Project 0 Queue Very good for most everyone Most everyone caught both bugs Most everyone’s reverse works Check your edge cases Test thoroughly on longer or less organized lists You can implement merge sort in-place (and someone did)

5. Project 0 Common Problem #1 • Linear probing misunderstandings • If using linear probing, you MUST mark a cell as vacated, which is different than free • Consider hash table size of 10 • Insert key1, hash = 5 & Insert key2, hash = 15 • Occupy positions 5 & 6 • Delete key1 • Lookup key2 – 5 is empty but need to look at six also

6. Project 0 Common Problem #2 • Properly handling set_hash_function() • Consider the following sequence: • Insert key1 w/hash = 5 under hash function a • Set hash function to b such that key1 has hash = 6 under hash function b • Look up key1, turns out to be empty! • Solutions? • Rehash! Or at least prevent the user from doing this if the HT is non-empty.

7. Project 0 Other Problems • Did not auto-resize their hashtable, or resize did not work properly. • Using int or char as key type instead of general type. • Settable hash function misunderstandings. • Memory leaks.

8. Coding Style • Having neat code makes a world of difference • If I can’t read your code and understand what its doing – you will lose points! (Especially if there are bugs) • Properly indent nested blocks • Always comment functions declared in .h files with their “contract” • What does it do? • What does it return? • What assumptions does it make about its arguments? • How does it indicate an error condition?

9. Coding Style • Write comments for tricky implementation sections: • Bad Comment: somePtr = NULL; // Set somePtr to NULL What a useless comment! • Good Comment: somePtr = NULL; // Always reset the pointer to // NULL after the shared memory // it points to has been freed

10. Coding Style • Always use header guards. Why? #ifndef FULL_PATH_TO_FILE_H_ #define FULL_PATH_TO_FILE_H_ // all your header file code here #endif /* FULL_PATH_TO_FILE_H_ */

11. Coding Style • Be consistent with your naming. • For functions • set_hash_function() style is ok • SetHashFunction() style also ok, just pick one and stick to it! • End typenames in _t, eg typedef foo_struct * foo_t; • Don’t abbreviate ambiguous variable names int n_comp_conns; // BAD – what is this? int num_completed_connections; // OK

12. What’s Wrong Here? void add(key_t k, value_t v) { …ht_node_t node = (ht_node_t)malloc(sizeof(ht_node));node->k = k;node->v = v;… } ht_node_t lookup(key_t k) { … return node; }

13. Memory Management • Always be explicit about who owns memory. • Consider: void do_stuff (char * buff, int len) { … free(buff); } int main() { char * mybuff = (char*)malloc(SZ * sizeof(char)); do_stuff(mybuff, SZ); // This frees mybuff … free(mybuff); // Double free – Undefined behavior! }

14. Memory Management • Consider one of two solutions: // do stuff assumes ownership of buffer buff and // deallocates memory allocated for buff. void do_stuff(char * buff, int len); • Or // Caller owns the memory pointed to by buff. void do_stuff(char * buff, int len) { // do not free(buff) here! } • Either way – memory ownership is explicit.

15. Memory Management • When to free memory? • What if two different places are holding on to a reference? • Reference counting. Drawbacks? • This is why platforms like Java and .NET have Garbage Collection.

16. So… What can we do here? void add(key_t k, value_t v) { …ht_node_t node = (ht_node_t)malloc(sizeof(ht_node));node->k = k;node->v = v;… } ht_node_t lookup(key_t k) { … return node; }

17. Project 1 Notes • Project 1 • Due Monday At 11:59pm! • Make it obvious who is in your group in write-up, also write your group letter! • Follow turnin instructions again – good job last time • Only one team member needs to use turnin • No turned in files should be outside of your “username-project1” directory.

18. Project 1 Notes • For changed Linux source files: • Give full path names in your modified files write-up • USE “./arch/i386/kernel/process.c” • NOT “process.c” – there are many of these • Maintain directories when submitting changed files: • When I extract your changed files, they should go to the right directory, so it is unambiguous which file you changed • This is easy to do with tar

19. Project 1 Notes • Use LXR to trace what the code does. • Libc wrappers versus syscalls? • Trace the code! • Fork versus Clone? • Trace the code! • Returning info from syscalls? • access_ok() checks pointers • copy_to_user() • return values work as well