Why is the printf Output Order Not Respected in a Concurrent Scenario with Piped or Redirected stdout?

We are in a concurrent scenario where we have **n** concurrent processes. By using a synchronization policy (e.g., using pipes or signals), each process can print using *printf("string\n")* only if it receives a token from the previous process, ensuring a specific printing order. When stdout is attached to a terminal (e.g., a console), the expected printing order is respected, meaning processes print in the exact order defined by the synchronization policy. However, when stdout is piped or redirected to a file or another process, the resulting printing order may not be respected, even though the processes still follow the synchronization policy correctly. We know that *printf* is buffered by default, meaning it does not immediately write to stdout but instead accumulates output in a buffer before flushing it. In a concurrent environment, it seems the operating system writes each process's buffer in an order independent of the intended synchronization policy, causing out-of-order prints. This is unexpected given that each process follows the policy correctly. However, this problem does not occur if one of the following solutions is implemented: 1. Forcing a flush after each call to printf using *fflush(stdout)*; 2. Disabling buffering for stdout in each child process using setvbuf(stdout, NULL, _IONBF, 0);. 3. Using the system call write(1, "string\n", strlen("string\n")); instead of printf, since write bypasses buffering and directly writes to stdout. Does anyone know why this happens? What is the operating system's policy regarding this?