Return to Video

03-25 Concurrent Software

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

03-25 Concurrent Software

more » « less
Team:
Udacity
Project:
CS258: Software Testing
Duration:
01:58
Udacity Robot edited English subtitles for cs258 unit2 20 l Concurrent Software
Amara Bot added a translation

English subtitles

Incomplete

Revisions Compare revisions