Re: WIP: Barriers

On Sat, Aug 13, 2016 at 4:18 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> First, you initialise a Barrier object somewhere in shared memory,
> most likely in the DSM segment used by parallel query, by calling
> BarrierInit(&barrier, nworkers). Then workers can call
> BarrierWait(&barrier) when they want to block until all workers arrive
> at the barrier. When the final worker arrives, BarrierWait returns in
> all workers, releasing them to continue their work. One arbitrary
> worker receives a different return value as a way of "electing" it to
> perform serial phases of computation. For parallel phases of
> computation, the return value can be ignored. For example, there may
> be preparation, merging, or post-processing phases which must be done
> by just one worker, interspersed with phases where all workers do
> something.

I think that this mechanism could be quite useful for sorting with
partitioning, which doesn't exist yet. What does exist is unlikely to
benefit from this over and above what Robert's "condition variables"
offer, because as it happens there is no need to "elect" a single
worker at all. The ordering dependencies happen to be quite naturally
across one leader process and one or more worker processes.

I do see value in this, though.

--
Peter Geoghegan