The implementation is incorrect because if two barrier invocations are used in immediate succession the system will fall into a DEADLOCK.
Here's how: Let all three processes make process_arrived variable to the value $3$, as soon as it becomes $3$ previously stuck processes at the while loop are now free, to move out of the while loop.
But for instance let say one process moves out and has bypassed the next if statement & moves out of the barrier function and The SAME process is invoked again(its second invocation) while other processes are preempted still.
That process on its second invocation makes the process_arrived variable to $4$ and gets stuck forever in the while loop with other processes.
At this point of time they are in DEADLOCK. as only 3 processes were in the system and all are now stuck in while loop.
Q.79 answer = option (B)
option (A) here is false as there will always be a need for some process to help some other process to move out of that while loop waiting. Not all processes together can be said to be completed at a time.
option (C) is false. If context switch is disabled then the process who was stuck in while loop will remain there forever and no other process can play a role in bringing it out of there as Context Switch will be required to bring that other process in the system to do the job.
option (D) is false. everyone will be in a loop forever, if that happens.
option (B) is TRUE. at the beginning of the barrier the $1^{st}$ process to enter Critical section should wait until process_arrived becomes zero(i.e. before starting its second invocation). this is to prevent it from making process_arrived value greater than $3$ i.e. rectifying the flaw observed in Q.78