To understand barriers, think of the times when you have planned to go to lunch with other people at your workplace. You agree to meet in the lobby of the building. Some of your coworkers reach the lobby early, and others arrive later. One comes running in last, apologizing. Finally, when all of you have gathered and you know that everyone is ready, you all leave the building in a group.
A barrier is the software equivalent of the lobby where you waited. A group of processes are going to work on a problem. None should start until all the data has been initialized. However, starting each process is part of the initialization, and they cannot all be started at the same time. Each process must be created; each must join an arena and perhaps open a file; and you cannot predict when they will all be ready. To coordinate them, you create a barrier. Each process, when it is ready to start the main operation, calls barrier(), passing the address of the barrier and the number of processes that will meet. When that many processes have called barrier(), all of them are released to begin execution.
The following functions are provided to manage and use barriers:
| new_barrier(3P) | Allocate and initialize a barrier in a specified arena. |
| free_barrier(3P) | Release the storage associated with a barrier. |
| barrier(3P) | Wait at a barrier until a specified number of processes have gathered. |
| init_barrier(3P) | Reinitialize a barrier (does not release any processes waiting). |
The main process allocates a barrier in some arena. To use the barrier, each process calls barrier(), passing the number of processes that are supposed to meet before proceeding. In a multiprocessor, each arriving process passes time by spinning.
Note: The barrier() function assumes that it is used on a multiprocessor. It always passes time by spinning in an empty loop. When used on a uniprocessor (or when used on a multiprocessor with fewer available CPUs than barrier processes), a call to barrier(n) can be quite inefficient. The waiting functions spin until each in turn uses up its time-slice. In general it is not a good idea to use barrier() except in a multiprocessor with a number of CPUs approximately equal to the number of coordinating processes.