On Sun, Aug 14, 2016 at 6:54 PM, konstantin knizhnik
<k.knizh...@postgrespro.ru> wrote:
> Barriers are really very simple and convenient mechanism for process 
> synchronization.
> But it is actually a special case of semaphores: having semaphore primitive 
> it is trivial to implement a barrier.
> We have semaphores in Postgres, but ... them can not be used by extensions: 
> there is fixed number of semaphores allocated based on maximal number of 
> connections and there is no mechanism for requesting additional semaphores.

Probably because they are kernel objects requiring extra resource
management.  I'm hoping for something that can be created dynamically
in DSM segments with no cleanup, and that aspect of semaphores is

> [...]  I wonder if somebody has measured  how much times latches 
> (signal+socket) are slower then posix semaphores or conditional variables?

I'm not sure if it makes sense for us to use POSIX conditional
variables: they require using POSIX mutexes, and we're pretty heavily
invested in the use of lwlocks that are hooked into our error handling
system, and spinlocks.

I'd be curious to know if you can make a better barrier with
semaphores.  I've attached a little test module which can be used to
measure the time for N processes to synchronise at M barrier wait
points.  You can run with SELECT barrier_test(<nworkers>, <nbarriers>,
<implementation>), where implementation 0 uses the barrier patch I
posted and you can add another implementation as 1.  This patch
requires lwlocks-in-dsm-v3.patch, condition-variable-v2.patch,
barrier-v1.patch, in that order.

This implementation is using a spinlock for the arrival counter, and
signals (via Robert's condition variables and latches) for waking up
peer processes when the counter reaches the target.  I realise that
using signals for this sort of thing is a bit unusual outside the
Postgres universe,  but won't a semaphore-based implementation require
just as many system calls, context switches and scheduling operations?

Thomas Munro

Attachment: barrier-test.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to