SWEA 2025 Weekplan 14

The learning goals for Week 49 are:

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

Literature:

Slides:

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 rehearsing some exam questions. No kata this week.

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)

Kata

Spend the first 15-20 minutes of the TØ/Lab class in plenum discussing...

No kata this week...

Optional Exercises:

These are optional exercises. Be sure to solve the mandatory project first, and only if you have a lot of spare time, try having a look at the exercises below.

Exam Rehearsal

Rehearse a exam situation. Spend 20-25 minutes to read and prepare a 10 minute oral presentation of one of the exercises in the example exam question set: demo-question-2025.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)?