Date: Fri, 24 Jun 2016 00:31:43 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Maxim Sobolev <sobomax@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, John Baldwin <jhb@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Alan Somers <asomers@freebsd.org>, Alan Cox <alc@rice.edu>, Alan Cox <alc@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, performance@freebsd.org, "current@freebsd.org" <current@freebsd.org> Subject: Re: PostgreSQL performance on FreeBSD Message-ID: <20160623223143.GC5381@stack.nl> In-Reply-To: <CAH7qZfvy46wWcrjz-ihA%2B%2BEYktm7PqGoJhj1a7hdYWssiEXFuA@mail.gmail.com> References: <20140627125613.GT93733@kib.kiev.ua> <CAJ-Vmom-M=R=FaBfHE5c2%2BYxW0SLmJTdFJD8tW4_aOD7MDNwzA@mail.gmail.com> <CAJ-Vmomt=WYjct%2BzsTbHuryxqYp7ELyS52LOb4NEsfENQ1yj1w@mail.gmail.com> <1603235.2ShtoCfSqO@ralph.baldwin.cx> <CAH7qZfuAtHtUG92wEjPhOZ=BGgyFS728uigjJoD0pG%2B-mtUSww@mail.gmail.com> <20160622100241.GM38613@kib.kiev.ua> <CAH7qZfvy46wWcrjz-ihA%2B%2BEYktm7PqGoJhj1a7hdYWssiEXFuA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 22, 2016 at 07:26:52AM -0700, Maxim Sobolev wrote: > Konstantin, > Not if you do sem_unlink() immediately, AFAIK. And that's what PG does. So > the window of opportunity for the leakage is quite small, much smaller than > for SYSV primitives. Sorry for missing your status update message, I've > missed it somehow. True, but if your process architecture supports that, you can also put unnamed process-shared semaphores into a piece of shared memory (pad sem_t to a cache line if contention is expected). This is more natural API use (fully avoiding the leak) and uses less memory. It has been supported for a long time, at least since FreeBSD 9.0. Process-shared mutexes, condition variables, reader/writer locks, etc. are available in FreeBSD 11 but use more memory (a 1-page object per synchronization object), somewhat like named semaphores. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160623223143.GC5381>