CSE 486/586 CSE 486/586 Distributed Systems PA Best Practices Steve Ko Computer Sciences and Engineering University at Buffalo.

Slides:



Advertisements
Similar presentations
Detecting Bugs Using Assertions Ben Scribner. Defining the Problem  Bugs exist  Unexpected errors happen Hardware failures Loss of data Data may exist.
Advertisements

Practice Session 7 Synchronization Liveness Deadlock Starvation Livelock Guarded Methods Model Thread Timing Busy Wait Sleep and Check Wait and Notify.
Concurrency Important and difficult (Ada slides copied from Ed Schonberg)
Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
Remote Procedure Call (RPC)
JAVA BASICS SYNTAX, ERRORS, AND DEBUGGING. OBJECTIVES FOR THIS UNIT Upon completion of this unit, you should be able to: Explain the Java virtual machine.
Debugging Introduction to Computing Science and Programming I.
Nov 10, Fall 2006IAT 8001 Debugging. Nov 10, Fall 2006IAT 8002 How do I know my program is broken?  Compiler Errors –easy to fix!  Runtime Exceptions.
Database Replication techniques: a Three Parameter Classification Authors : Database Replication techniques: a Three Parameter Classification Authors :
16-Jun-15 Exceptions. Errors and Exceptions An error is a bug in your program dividing by zero going outside the bounds of an array trying to use a null.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Exceptions. Errors and Exceptions An error is a bug in your program –dividing by zero –going outside the bounds of an array –trying to use a null reference.
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Computer Science 162 Section 1 CS162 Teaching Staff.
Building Secure Software Chapter 9 Race Conditions.
29-Jun-15 Java Concurrency. Definitions Parallel processes—two or more Threads are running simultaneously, on different cores (processors), in the same.
Debugging CMSC 201. Announcements Hw2, Hw3 grades returned if something doesn’t seem right, ask Midterm next Thurs (Oct 23) we’ll review on Tues no hw.
CHAPTER 10 Recursion. 2 Recursive Thinking Recursion is a programming technique in which a method can call itself to solve a problem A recursive definition.
Fundamentals of Python: From First Programs Through Data Structures
Discussion Week 3 TA: Kyle Dewey. Overview Concurrency overview Synchronization primitives Semaphores Locks Conditions Project #1.
JS Arrays, Functions, Events Week 5 INFM 603. Agenda Arrays Functions Event-Driven Programming.
CSE 486/586 CSE 486/586 Distributed Systems PA Best Practices Steve Ko Computer Sciences and Engineering University at Buffalo.
1 Testing Concurrent Programs Why Test?  Eliminate bugs?  Software Engineering vs Computer Science perspectives What properties are we testing for? 
CC0002NI – Computer Programming Computer Programming Er. Saroj Sharan Regmi Week 7.
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
1 Chapter Eight Exception Handling. 2 Objectives Learn about exceptions and the Exception class How to purposely generate a SystemException Learn about.
Jun 16, 2014IAT 2651 Debugging. Dialectical Materialism  Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes.
Nachos Phase 1 Code -Hints and Comments
Programming with Alice Computing Institute for K-12 Teachers Summer 2011 Workshop.
ICAPRG301A Week 4Buggy Programming ICAPRG301A Apply introductory programming techniques Program Bugs US Navy Admiral Grace Hopper is often credited with.
Structured programming 4 Day 34 LING Computational Linguistics Harry Howard Tulane University.
General Programming Introduction to Computing Science and Programming I.
CMSC 202 Exceptions. Aug 7, Error Handling In the ideal world, all errors would occur when your code is compiled. That won’t happen. Errors which.
Errors And How to Handle Them. GIGO There is a saying in computer science: “Garbage in, garbage out.” Is this true, or is it just an excuse for bad programming?
Java Threads 11 Threading and Concurrent Programming in Java Introduction and Definitions D.W. Denbo Introduction and Definitions D.W. Denbo.
1cs Intersection of Concurrent Accesses A fundamental property of Web sites: Concurrent accesses by multiple users Concurrent accesses intersect.
Security - Why Bother? Your projects in this class are not likely to be used for some critical infrastructure or real-world sensitive data. Why should.
DEBUGGING. BUG A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected.
Games Development 2 Concurrent Programming CO3301 Week 9.
Systems Life Cycle. Know the elements of the system that are created Understand the need for thorough testing Be able to describe the different tests.
CSC 142 D 1 CSC 142 Instance methods [Reading: chapter 4]
1 Chapter 3 Syntax, Errors, and Debugging Fundamentals of Java: AP Computer Science Essentials, 4th Edition Lambert / Osborne.
The Software Development Process
Chapter 3 Syntax, Errors, and Debugging Fundamentals of Java.
Fall 2002CS 150: Intro. to Computing1 Streams and File I/O (That is, Input/Output) OR How you read data from files and write data to files.
Exceptions Chapter 16 This chapter explains: What as exception is Why they are useful Java exception facilities.
Data Structure Introduction Dr. Bernard Chen Ph.D. University of Central Arkansas Fall 2010.
Error Handling Tonga Institute of Higher Education.
The single most important skill for a computer programmer is problem solving Problem solving means the ability to formulate problems, think creatively.
Locking In CFML. Locking in CFML - Why - How - What - When } to lock? Understand Locking.
MULTIVIE W Slide 1 (of 21) Software Transactional Memory Should Not Be Obstruction Free Paper: Robert Ennals Presenter: Emerson Murphy-Hill.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Android Programming Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586 CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo.
Exceptions Lecture 11 COMP 401, Fall /25/2014.
Agenda  Quick Review  Finish Introduction  Java Threads.
Announcements Assignment 2 Out Today Quiz today - so I need to shut up at 4:25 1.
Advanced Taverna Aleksandra Pawlik University of Manchester materials by Katy Wolstencroft, Aleksandra Pawlik, Alan Williams
Lecture 5 Page 1 CS 111 Summer 2013 Bounded Buffers A higher level abstraction than shared domains or simple messages But not quite as high level as RPC.
Tutorial 2: Homework 1 and Project 1
Introduction to Computing Science and Programming I
CSE 486/586 Distributed Systems Leader Election
CSE 374 Programming Concepts & Tools
Testing and Debugging.
Lecture 25 More Synchronized Data and Producer/Consumer Relationship
Java Concurrency.
Java Concurrency.
CSE 486/586 Distributed Systems PA Best Practices
January 15, 2004 Adrienne Noble
Exceptions 10-May-19.
CMSC 202 Exceptions.
Presentation transcript:

CSE 486/586 CSE 486/586 Distributed Systems PA Best Practices Steve Ko Computer Sciences and Engineering University at Buffalo

CSE 486/586 First Things to Keep in Mind Your implementation is necessarily going to be full of bugs. –Your job is to reduce the number of bugs as many as possible before submitting it. Correctness first. Performance later. –Don’t even think about performance optimization in your first-cut implementation. You will not do it correctly. Know how to use sockets precisely. –What does accept() do? What is a port number? What is socket timeout? What do read(), write(), and flush() do? –There is no other way but reading the documentation thoroughly. 2

CSE 486/586 First Things to Keep in Mind Know the constructs and data structures precisely. –AsyncTasks, Threads, Cursors, etc. –Once again, read the documentation thoroughly. Write your code systematically. –Write a small chunk, test, and repeat. –If you’re writing a hundred lines of code before testing it, there’s something wrong. Structure your code well. Simplify. –Use simple, one-shot tasks (e.g., request-response) that work independently, asynchronously, and mostly serially. –A rule to compare: if your method has more than 20 lines, think why you’re doing it and convince yourself that it’s necessary. 3

CSE 486/586 First Things to Keep in Mind Follow good style conventions –Strive to write maintainable and professional-looking code Know answers to questions like the following. –What is the Java comment style convention? –Where are good places to define a field? –What are good ways to catch exceptions? –What is a good indentation convention? –What are good variable/method naming conventions? –What is a good brace style? –What are good line lengths? Good sources – – 4

CSE 486/586 First Things to Keep in Mind Embrace concurrency –Dealing with concurrency is your make-or-break point for all later assignments. –Keep in mind that your code will behave in a non- deterministic way with multiple threads. –We still expect your code to produce deterministic results. –You will need to come up with your own test cases and testing strategies (more on this later). –You will need to run the graders multiple times and make sure that you get the same results consistently. Serialize as much as possible. –Do one thing at a time. –Use a lock on every shared variable. 5

CSE 486/586 First Things to Keep in Mind Don’t be caught up with just one way of doing things. –Start early. –Ask and explore if there is any other way of doing the same thing. –Learn why one way is better than the other. –This often results in a better, faster outcome. Use logging statements for debugging. –Almost the only way to debug things for distributed systems. –Once deployed, the only way to debug your code in any system. –Open logcat for each instance in a terminal. –It’s OK to put a lot of logging statements. Just remove really unnecessary ones later. –Be aware that logging statements alter the code behavior. 6

CSE 486/586 First Things to Keep in Mind Do not use graders as your debugger. –Graders do not know what you’re doing. They only verify what you’re returning. –They will try to give you reasons why they are complaining. But this by no means gives you enough information for debugging. –When a grader complains about something, the first thing you need to do is NOT deciphering the grader’s message; you need to look at your own logs and pinpoint what’s going on. 7

CSE 486/586 First Things to Keep in Mind Do not assume that Android or graders are broken. –It’s almost always your code. Blaming other systems only reveals your immaturity as a developer –In general, if you’re developing with a large-scale system, it’s always tempting to think that the other system is broken, not yours. –That’s almost always wrong, unless you have a very well- thought-out reason verified by people knowledgeable about the internals of the other system. –OK, I admit that sometimes it might be the case. But it is very rare in the context of our class. –(Disclaimer: It is generally good to be suspicious about what’s going on outside your code; it gives you learning opportunities and you might actually find a bug that no one has encountered.) 8

CSE 486/586 First Things to Keep in Mind You will write complex code, so make sure that you have your own testing strategy –Graders are convenient, indeed. However, it is just not enough for testing and debugging. –This is especially true with concurrency, since a bug may not manifest deterministically. There can be many conditions that lead to deadlocks and livelocks. –It’s best to develop your own test cases that stress your system. 9

CSE 486/586 More Specific Things Socket –Know how exactly it works. E.g., accept() returns a new socket. –Know how to use socket timeout, which only times out when reading (not writing, not accepting, etc.). –Use it as a write/read pair (and check on the returning read for failures), or even better, continue using the same socket as long as possible. AsyncTask –Be aware: there is a limit of how many you can create and execute at the same time (a concept called thread pools). This is system-dependent, but on our emulator, it seems to be 5. –You can wait for a result using AsyncTask.get() 10

CSE 486/586 More Specific Things Threading –Understand how threads behave and synchronization works. E.g., what happens if you call Thread.sleep() in the middle of an execution? What happens with wait() and notify()? –If you have threads, but don’t use locks or synchronized, you’re probably doing something very wrong. Messages –Do not send a whole object (Serializable). Takes a long time, unnecessarily big, and just a lot of overhead. –Formatted strings should be enough. 11

CSE 486/586 More Specific Things Logging –Concurrency is difficult to debug and extensive logging is pretty much the only reliable way. –You need to be able to trace out all interactions, e.g., communication originated from one peer to all other peers and coming back (use and log message IDs, message types, etc.) –You need to be able to keep track of each thread’s progress, e.g., is this method call blocked or returning? Is this for loop moving on to the next iteration? Is this loop terminating properly? Know how to use adb –adb devices –adb kill-server/start-server –adb install/uninstall/insert/query 12

CSE 486/586 More Specific Things Grader related –Check the output of a grader carefully. They do not always print out a potential error at the end. –Graders use string matching to check the results. Be careful about extra whitespaces you might be inserting. onCreate() –This should not do any long-running operation. If onCreate() takes a long time to return, it might give you unexpected problems, e.g., it might get called multiple times. –This is especially true with a ContentProvider. If onCreate() is being executed and there’s an insert() or a query() call, onCreate() will be called again. 13

CSE 486/586 More Specific Things Callback method signatures –Do not change the signature of a callback method you implement, e.g., query(), insert(), etc. They are all defined by Android, and Android doesn’t expect any change. –For example, don’t add synchronized to query() or insert(). It will behave in an erratic way. Failure detection –You can use a regular request/reply as a failure detection mechanism. –For this, always reply back with something so the other side knows that you’re alive. Do not write a custom busy-wait in your code –Don’t use a loop and check whether or not a condition is true. Use Java primitives such as wait()-notify(). 14