1. Topics in Software Bug Detection Instructor: Murali Krishna Ramanathan

2. What?  Automated bug detection  Design and implementation of algorithms  Emphasis on concurrency  Deadlocks  Race conditions  Atomicity violations  Use Java for explanation  Java Concurrency in Practice – Goetz et al  Discussion of papers  Detection  Reproduction  Prevention  Testing  Miscellaneous

3. Why?  Software testing has limitations  Not scalable  Dependent on quality of test inputs  Human intensive  Challenges  Exciting problems to solve (M.Sc/PhD research topics)  Implementation intensive projects (M.E projects)  Job prospects  Better programmer  New industry  Many companies have program analysis positions  Write analysis tools customized to company’s codebase  Easy grades, less work to finish course requirements - NO

4. When and Where?  Wednesday and Friday  8 – 9:30 am  CSA 252  Office hours  9:30 – 10:30 am  CSA 211  Subscribe to spring13-310@csa.iisc.ernet.in for announcements  Send email to jags@csa.iisc.ernet.injags@csa.iisc.ernet.in  Class Webpage:  http://www.csa.iisc.ernet.in/~muralikrishna/teaching/spring2013 /e0310.html

5. Course timeline  Understand concepts of concurrency in Java  Jan and part of Feb  Discuss papers  Rest of the semester  Maximum of 4  Weightage: 15%  Homework Assignments  Jan 22 nd and Feb 5 th due  Weightage: 15%  Project  Maximum of 3 members in a team  Proposal due by Feb 28 th  Final demo due by April 25 th.  Weightage: 50%  Emphasis on novelty, applicability to real code

6. Project  Use git to maintain revision history  Contributions evaluated based on the history  No free riders  Use latex for generating project report  Use a build system for development  Java – apache ant, maven, etc  C/C++ -- make  Source code should have sufficient comments  Suggested – use javadoc style comments  All the above will be checked as part of the demo

7. Midterm  End of march  Open book, open notes, open web exam  No need for memorization  Concepts from papers discussed will be part of syllabus

8. Expectation from the course  Understand the complexities of concurrent programming  Ability to implement any program analysis tool  Familiarity with git, latex, {ant, make, maven, …}  Better programmer

9. Background  Single program at a time  Inefficient use of resources  Multiple programs at a time  Process  Resources  Memory  File handles  Security credentials  Communication  Sockets  Signal handlers  Shared memory  Semaphores  files

10. Why multiple programs at a time?  Resource utilization  Wait for I/O by P1  Let P2 run to effectively use the CPU  Fairness  Users and programs have equal claims  Convenience  Simple to write a dedicate program  Complex to write a program to handle multiple tasks

11. Threads  Light weight process  Share process-wide resources  Memory  File handles  Dedicated  Program counter  Stack  Local variables  Sharing data  Use explicit synchronization  The source of many problems

12. Benefits of threads  Improve performance  Efficient use of resources  E.g., responsiveness of GUI  Exploits multiple processors  Commodity hardware – multiple cores  Single threaded application on a 100 core system  Wastage of 99% of computing power  Simplicity of modeling  Simplicity of writing programs  Straight line code  Web application frameworks  Servlet’s service, doPut, doGet methods handle multiple requests  Each request executed in a single thread

13. Benefits of threads (continued)  Simplified handling of asynchronous events  Single threaded applications use non-blocking I/O  Complicated and error prone  Each request in its own thread  Synchronous I/O  More responsive user interfaces  Otherwise, frozen UI.

14. Problems with threads  Safety  Unpredictability of results

15. Execution of UnsafeSequence.nextValue

16. Sharing memory address space  Advantages  Convenient  Other inter-thread communication mechanism can be complicated  E.g., counter for the number of web client requests  Downside  Non-sequential control flow  Access needs to be coordinated

17. Thread-safe sequence generator

18. Problems with threads (contd.)  Liveness hazards  Inability to make forward progress  Infinite loops in sequential programs  Other problems in concurrent programs  Deadlock  Livelock  Performance hazards  Overheads associated with context switching  Saving and restoring execution context  Loss of locality  CPU time used on scheduling  Synchronization costs  Inhibits compiler optimizations  Flush/invalidate memory caches  Create synchronization traffic on shared memory bus

19. Why think about thread-safety?  Frameworks create threads  Hence, thread-safety needs to be considered  JVM uses threads  Garbage collection, etc.  AWT and Swing UI  Threads for user interface events  Servlets, RMIs,…  Thread pools are created  TimerTasks  Actions invoked on certain timer events

20. Thread safety  Object’s state stored in state variables  Instance fields  Static fields  Object’s state can be dependent on other object’s state.  Class A { B b;}, class B {int x;}  State variables  Shared – by multiple threads  Mutable – can change value after initialization  Use synchronization to coordinate access to object’s mutable state

21. Shared variables  Multiple threads access the same mutable state variable without synchronization  Program is broken  How to fix it?  Multiple threads -> single thread (do not share)  Mutable -> immutable (do not change state)  Without synchronization -> with synchronization  Design classes for thread-safety  Retrofitting is hard

22. Thread safety and Object-oriented techniques  Encapsulation  Using static fields should be avoided to the extent possible  Make fields private and access using public methods  Immutability  Clear specification of invariants  Pre and post conditions  Thread shared behavior

23. Performance vs Correctness  Encapsulation can conflict with performance  Choose other ways to address performance issues  Between performance and correctness  Choose correctness  Then performance  Losing encapsulation  Thread safety becomes hard, but possible  Maintenance harder

24. What is thread safety?  … can be called from multiple program threads without unwanted interactions between the threads  … may be called by more than one thread at a time without requiring any other action on the caller’s part  Fuzzy definition  Correctness  Class conforms to its specification  Define invariants  Post-conditions describe effects of its operations  Are specifications practical?  Code confidence

25. Thread safety  Class is thread-safe  Behaves correctly when accessed from multiple threads  Independent of scheduling/interleaving of threads  No additional synchronization  No other coordination on part of calling code  Thread safe classes  Encapsulate any needed synchronization  Clients don’t need to provide their own

26. Stateless objects  Always thread safe

27. Objects with states - Atomicity

28.  Read-modify-write operation  Incorrect results due to unlucky timing  Race condition  Check-then-act pattern  Do not always cause a problem  Makes debugging even harder

29. Lazy initialization

30. Compound actions  Sequence of operations need to be atomic  Operations on the same state  Example of atomic operations  Check-then-act  Read-modify-write  Thread-safe objects  AtomicLong, AtomicInteger, etc

31. Example using AtomicLong

32. Multiple states in thread-safe object  Update related state variables atomically

33. Intrinsic locks  “synchronized” block (in Java)  Reference to object that will be the lock  Block of code guarded by the lock  synchronized(lock) { … }  Only one thread acquires the lock  Synchronized region is accessible only to the thread that acquired the lock  Ensures atomicity of operations on related state variables

34. Reentrancy  Ability to acquire a held lock by the same thread. Synchronized (lock) { … synchronized(lock) {…}…}  Lock acquisition - increment acquisition count  Another thread acquires lock when count is 0  Lock release – decrement  Intrinsic locks in Java are reentrant  Non-reentrant locks  Acquisition on a per-invocation basis

35. Guarding state with locks  Synchronization to coordinate access to variable  Everywhere that variable is accessed.  Acquire the same lock  Synchronization needed for read operations as well  If there is at least one write operation  Specify clearly the guarded by relationship  Synchronization does not address all concurrency issues  Atomicity of two synchronized operations  if(!vector.contains(element)) vector.add(element);

36. Performance considerations

37. Liveness and performance  Granularity of synchronized blocks  Too coarse – performance suffers  Too fine – correctness problems  e.g., synchronizing the service() method  Only one request serviced at a time

38. Correct example – Atomicity of operations

39. Design suggestions  Tradeoff between simplicity and performance  Simplicity first  Avoid holding locks for lengthy computations  Network I/O  Console I/O  Loops  Sleep