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 problematic. > [...] 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 http://www.enterprisedb.com
Description: Binary data
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers