On Sun, Aug 14, 2016 at 6:54 PM, konstantin knizhnik
<k.knizhnik@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
allocatedbased 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
problematic.
> [...] I wonder if somebody has measured how much times latches (signal+socket) are slower then posix semaphores or
conditionalvariables?
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
http://www.enterprisedb.com
