Re: WIP: Barriers
От | Thomas Munro |
---|---|
Тема | Re: WIP: Barriers |
Дата | |
Msg-id | CAEepm=0TGUsAQs_7OoO+bg4Z+fksdeFADG8qFKTwk51_EDRObQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Barriers (konstantin knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: WIP: Barriers
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: