The chat log didn't turn out to be very informative, so I've taken the liberty of writing a summary of the Q&A.


The 1st question was related to solving C and D in a parallel way:

If you split a[] between threads, and want them to sort into b[] by digits, you might run into a problem.
Consider the sequential solution to C:
  You know from B how many occurrences there are of each digit. From that, you can just generate pointers accordingly. If you have 3 occurrences of numbers with digit = 0, you want indexes 0, 1, and 2 in b[] to be allocated to those numbers. And then you just copy these numbers from a[] to the correct range of indexes in b[].

If you do the exact same thing in your parallel solution in addition to splitting a[] between threads, you're going to run into some index-related problems:
  Say you have 4 threads; T0, T1, T2 and T3. All of which searches their fourth of a[] for numbers with digit = 0;
  If you're accumulating like the sequential solution and sync correctly, you'll find the correct indexes in b[] that should be reserved for those numbers, but that's not all there is to it!

  What happens if T3 adds a number with digit = 0 at the same index and the same time as T1 attempts to do the same? <--- Bad things, that's what.
  Just finding the range of indexes where numbers with a certain digit are supposed to go in b[] and moving them accordingly with ++ works sequentially, but we need to add another dimension to the parallel solution.

  Basically in addition to knowing the index range where numbers of a certain digit goes, each thread needs to be aware of which index within that index range they're allowed to add numbers from.
  Ex.

    T0 finds 3 numbers with digit = 0 in its part of a[]. T1 finds 2 numbers with digit = 0 in its part of a[]. T1 is not allowed to place either of its numbers into indexes 0 or 1, because that should be reserved for T0. So T1 needs to know the frequency of the number with digit = 0 found by T0. Likewise, T2 will need to know the frequencies found by both T0 and T1. T3 will need to know frequencies found by T0, T1, and T2. And so forth.

    BIG HINT: this can be solved using 2D arrays where each thread has a row with frequency values accumulated from the corresponding indexes in the preceding rows (threads). Check out this code snippet from my solution from back in the day:

    // each thread counts frequencies (B) in their own part of the array (localCount), and allCount is a 2D array where each row is the local frequency count array for each thread.

    for (int i = 0; i < localCount.length; i++){	// C
      for (int j = 0; j < id; j++){
        accumulator += allCount[j][i];
   }


  The 2nd question was whether there is any reason to paralyse C:

  Magnus Espeland (group teacher from last year and the year before) pointed out that there is no reason to paralyse C because there isn't really a lot of work being done in that step, i.e. paralysing it is inefficient compared to just doing it sequentially. However, the assignment text specifies that C and D should be paralysed so what to do?
    - If you can argue that performing step C sequentially is more efficient than performing it parallel, I see no reason as to why you should paralyse step C. The name of the game is 'efficiency' so what's  the point if it's not more efficient?
    - If you can't, the safe approach is obviously to paralyse it.


  The 3rd question was when digital lectures are supposed to resume:

  The answer to that is as of next week! The faculty forbade/forbidded/whatever-'forbidden'-in-the-past-tense-is teaching until they had a strategy for digital solutions in place. They do now, and from Monday (23.03.20) lectures and group sessions will resume using Zoom in this course.