English subtitles

← 03-25 Concurrent Software

03-25 Concurrent Software

Get Embed Code
1 Language

Showing Revision 2 created 07/16/2014 by Udacity Robot.

  1. Now, let's talk about a slightly different issue, which is, "What we should do
  2. about test coverage for concurrent software?"
  3. Now in general in this class, we haven't been dealing at all with testing of concurrent code
  4. and this mainly it is a difficult and specialized skill.
  5. Let's talk briefly about what coverage of concurrent software would actually mean.
  6. First of all, hopefully it's clear that while applying sequential code
  7. coverage metrics to concurrent software is a fine idea.
  8. Probably, these aren't going to give us any confidence with the code lacks
  9. concurrency here such as race condition and the deadlocks.
  10. So let's talk about how we would figure out if we've done a good job testing concurrent software.
  11. So let's take for example this function x fer, which transfer some amount of money
  12. between bank account one and bank account two.
  13. This particular function is designed to be called from different threads.
  14. So what I've done here is mark a1 and a2 in red and these variables are representing the different
  15. bank accounts and then red in order to indicate that these are shared between different calls to x fer.
  16. And so the transfer function is going to be called from one thread so some thread is going to transfer
  17. money between accounts and also several other threads are going to do the same thing.
  18. So we have is multiple threads calling this transfer function and as long as the threads are moving
  19. money between different accounts, probably everything is all right.
  20. On the other hand, since the transfer function does not synchronize--
  21. that is it hasn't taken any sort of a lock while it manipulates the accounts.
  22. If these threads are operating on the same accounts concurrently, then it's going to be a problem.
  23. We're going to mess up the balances of the accounts that are involved.
  24. And so I ask the question, "What sort of coverage what we be looking for
  25. while testing this function in order to detect this kind of bug?"
  26. And the answer is some sort of a coverage metric to make sure that threads T1 and T2
  27. both call this function at the same time while transferring a money between the same accounts.
  28. So the coverage would essentially be T1 gets part way into the function
  29. and then let's say it stops running, the processor then starts to run T2
  30. for which it operates on the accounts and then completes and then this interleaving of actions
  31. between the different threads would be what would constitute a unit of test coverage so that is to say
  32. we want to make sure we tested the case where the transfer account is concurrently call.
  33. So that's one kind of coverage that we might look for when testing concurrent software.