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?