SWEA 2023 Weekplan 14

The learning goals for Week 49 are:

Mon: Exam Discussion. Wed: Concurrency and Thread Programming. (Screencasted only).

Literature:

• [Christensen, 2023] How to pass the exam (PDF)
• [Jenkov, 2014] Cursory: Sections "Java Concurrency and Multithreading Tutorial", "Creating and Starting Java Threads", "Race Conditions and Critical Sections", "Thread Safety and Critical Sections", "Java Synchronized Blocks", "Thread Signalling", "Deadlock", "Locks in Java", "Blocking Queues".
  Optional: Sections "Multithreading Benefits", "Multithreading Costs", "Concurrency vs. Parallelism", "Deadlock Prevention", "Starvation and Fairness". (Online)

Slides:

• W14-1 Exam (powerpoint) // (PDF)
• W14-2 Concurrency (powerpoint) // (PDF) // Associated Screencast
• W14-3 Shared Resources (powerpoint) // (PDF) // Associated Screencast
• W14-4 Producer Consumer (powerpoint) // (PDF) // Associated Screencast
• W14-5 Multithreaded Servers (powerpoint) // (PDF) // Associated Screencast

Notes for this weekplan:

Monday lecture starts at 9.15, and I will spend the time on talking about the exam. Wednesday is cancelled and replaced by screencasts.

I advice spending the last Lab session on preparing for the exam by doing the (exam related) Kata and rehearsing the exam questions.

In looking for good resources on concurrency in Java, I actually found Jenkov's tutorial pages quite OK; so we will use them instead of a book. Note that in some of the later sections, Jenkov himself implements for instance Lock - you may skip these descriptions as Java 1.5 and later provides Lock implementations.

The slides contains several small code examples. You can find most below:

1. ThreadDemo2
2. CounterTest
3. Producer/Consumer (ZIP)

Additional exercises:

Kata ... Test-Driven Development or not

At the exam, I quite often see students who do not get the TDD process right. The proper One Step Test is important and it requires a bit of analysis. Pitfalls I see are

1. Make a 'fake-it-till-you-make-it' test case in first iteration (which is fine), but then selecting new test cases in iteration 2+3 which are actually satisfied by the same 'fake-it' production code. No progress is made.
2. Make a 'fake-it-till-you-make-it' test case in first iteration (which is fine), a second iteration that triangulates a bit of the algorithm for a part of the requirement (which is fine), but then in the third iteration add a test case which is focussed on a completely different requirement of the specification. Loosing focus.
3. Make a 'fake-it-till-you-make-it' test case in first iteration (which is fine), but in the second iteration, starting to add production code which is not driven by tests, that is much more production code than required by the just added test case. Not taking small steps.

Consider the "Danish CPR number pretest" exercise (0.4) from the exam question set: demo-question-final-2023.pdf

Assume that a student has made iteration 1 by selecting test list item * The cpr "321201-3217" is invalid, its first two digits are above max of 31, then made the test

@Test
public shouldRejectDate32() {
  assertThat(tester.preTestCPR("321201-3217"), is(false));
}
        

and implemented fake-it-till-you-make-it code

public boolean preTestCPR(String cpr) { return false; }
        

... then provide examples of the next 2-3 iterations (sketch JUnit code) which falls in the above mentioned traps of

1. Not making any progress
2. Loosing focus
3. Not taking small steps

Next, sketch 2-3 iterations' JUnit code that does make progress, keeps focus, and takes small steps.

Exam Rehearsal

Rehearse a exam situation. Sit down and spend 20-30 minutes to read and prepare a 10 minute oral presentation of one of the exercises in the example exam question set: demo-question-final-2023.pdf.

Next, do a 10 minute presentation at the whiteboard in front of your team.

The team provides constructive feedback on the presentation: Is your presentation clear and understandable, do you discuss the concepts and terms correctly, is you Java example code correct, correct UML, etc. Swap and ensure all in the team gets a chance to rehearse the situation.

CounterTest

The 'CounterTest' program above is not thread-safe. Make it proper thread-safe by:

1. Use 'synchronized'
2. Use ReentrantLock class
3. Use the AtomicInteger class

TeleMed Concurrency Issues

The TeleMedServant is the central implementation for the server side of the TeleMed system and as such acts as a Facade pattern for a subsystem of some complexity behind it: XDS database and its current FakeObject implementation, HL7 generation using builder pattern, etc.

The current design is not thread-safe! That is, it will occasional fail in case multiple threads concurrently invokes 'processAndStore()', 'getObservationsFor()', etc., which can occur if we have a multi threaded server (as the URI Tunnel version is) that is under high load.

You are required to:

1. Demonstrate the failure(s) by testing. That is, write a main() program that creates one TeleMedServant object, spawns 100 threads that in their run() method performs a couple of hundred processAndStore() and getObservationsFor() calls on that single TeleMed instance with a few milliseconds delay in between. Start them all, and see the failure occur now and then. (Have a look at the ProducerConsumer codebase to see its main program and model your code after that.) If no errors occur - more threads, more calls, shorter delays!
2. Fix the concurrency issue. What class of concurrency issue is it (shared resource or producer-consumer)?

Legend: The typography bold, normal, (brackets), above indicate my perception of how important the exercises are from high to optional. However, solve the mandatory project first!