This question is basically two-fold:

1. How do you solve the actual problem? and
2. How do you generally read in graph data?

The first question is a bit narrow, and it sounds like the second one is of more interest to you in the long run. So, let me just point you to flow algorithms. It's a step up from Dijkstra in terms of implementation complexity, but as you already realized, there is just so much you can do with a single path. Network flows are a whole different thing.

As for reading your input, it dramatically depends on the kind of graph library you want to use. A few years ago, when I was active in these competitions, we weren't allowed to use 3rd-party libraries, so had to roll our own implementations.

In that case, you have to think ahead if you want to read in a complete matrix, or if you want to keep the graph as an adjacency list. These are the two most important data structures to know for graph algorithms. (more precisely, often you don't need to think ahead, because the problem input specification directs you to one or the other)

Reading input for an adjacency matrix is as straightforward as two nested for-loops. In the body of the inner loop, you simply read one value and assign it to one matrix cell. Done.

For adjacency lists you need to prepare the list of neighbors of a node for each of the nodes, i.e. for n nodes you prepare a list of size n that contains an empty list for each entry. Then you again have two nested for-loops: the outer loop goes over the nodes, the inner loop reads the neighbors of that node and adds them to the corresponding inner list. Voila - an adjacency list representation of the graph.

Important addition for programming challenges/competitions: Make sure that you know in your dreams how to write both variants before you even think about competing. There are limitless sample questions and practice sites out there. Search around for problems with graph input, then write and rewrite the input code again and again. It should almost always be nearly the same code, and once you've grown accustomed to it, reading in input like the one you gave above takes you 5 minutes at most. If you want to compete with the really strong players in that field, you should be able to code the input reading for this within about 1 minute or less.

Your process description seems to suggest that P1 needs data read by P3 (c1), P2 needs data read by P3 (c2), and P3 needs data read by P1 and P2 (a2 and b1).

So, is this what needs to happen (where * can occur anytime after 2):

1. P1 <- read a1
2. P3 <- read c1
3. P3 <- read c2
4. P2 <- read b1 and b2 *. P1 <- read a2

Or do P1, P2, and P3 use a cache of the last value read in the other process?

If the latter, you just need one mutual exclusion semaphore to control access to the device. If the former, you can have a fourth process that handles reading all the data and synchronize on when a valid set is available for all the use and when the data set has been read by all parties.

The fourth process doesn't have to know ahead of time what the data to be read is, it can simply implement a message queue where P1, P2, and P3 send it the parameters for data to be read. It then incrementes a counting semaphore each time it completes reads from each process. After sending their read message, everyone waits until the "data ready" semaphore reaches 3, then knows a valid set of data is available. After doing a read, they in turn increment a "data read" semaphore and wait for it to reach 3. When it does, they then wait on the "data ready" semaphore to go to 0 (the fourth process handles this after everyone has signaled their read, setting the "data ready" semaphore back to 0 then the "read data" semaphore back to 0. and the whole process repeats itself. Note, you'd never have a case where a process could miss the transition back to zero (deadlock) since each process needs to signal that their read is complete before the wait for "data ready" to go to zero by the time the third process gets around to doing it's read.

So, bottom line, you should be able to implement this with either 1 semaphore or 2 depending on what your requirements are for a concurrent set of data.

EDIT - Reviewing this, the "data ready" semaphore doesn't need to be a counting one since the thread with sole ownership of the input device can simply keep an internal count and just signal once when a complete data set is ready.