Sortof, the pipeline works like this: it first executes the first command and then the second command in your case.
That is, let's have
A|B be the command given. Then it is uncertain whether
B starts first. They might start at exactly the same time if there are multiple CPUs. A pipe can hold an undefined but finite amount of data.
If B tries to read from the pipe, but no data is available,
B will wait until the data arrives. If
B was reading from a disk,
B might have the same problem and need to wait until a disk read finishes. A closer analogy would be reading from a keyboard. There,
B would need to wait for a user to type. But in all of these cases, B has started a "read" operation and must wait until it finishes. But if
B is a command such that it needs only partial output of
A then after certain point where
Bs input level is reached
A will be killed by SIGPIPE
A tries to write to the pipe and the pipe is full,
A must wait for some room in the pipe to become free.
A could have the same problem if it was writing to a terminal. A terminal has flow control and can moderate the pace of data. In any event, to
A, it has started a "write" operation and will wait until the write operation finishes.
B are behaving as co-processes, although not all co-processes will be communicating with a pipe. Neither is in full control of the other.