Re: BUG #14206: Switch to using POSIX semaphores on FreeBSD

Konstantin, would it be too much to ask to start running your tests using
unnamed semaphores instead for your performance work? As far as I properly
understand what Tom said, named code was kinda one-off workaround for some
specific ancient version of Darwin not used by any other platform that the
PG cares about, so it might rot and/or get nuked eventually. Therefore, we
might get better chance to get our changes accepted into the PostgreSQL if
we use unnamed option. And they are not using "named" part anyway for
anything functionally important, so unnamed POSIX semaphore is naturally
the best primitive to use. This might also stir some interests among other
OSes to switch to that. Thanks!

-Max

On Wed, Jun 22, 2016 at 3:00 AM, Konstantin Belousov <kostikbel(at)gmail(dot)com>
wrote:

> On Tue, Jun 21, 2016 at 04:36:02PM -0400, Tom Lane wrote:
> > Maxim Sobolev <sobomax(at)freebsd(dot)org> writes:
> > > Tom, thanks for looking at it so promptly. I am adding kib@ into the
> > > discussion. Perhaps he would comment on the SYSV vs. POSIX in FreeBSD
> and
> > > named vs. unnamed.
> >
> > BTW, I trawled our archives and found this thread concerning the switch
> > from POSIX to SYSV on OS X:
> >
> >
> https://www.postgresql.org/message-id/flat/3830CBEB-F8CE-4EBC-BE16-A415E78A4CBC%40apple.com
> >
> > I'm not sure what you were using to decide that POSIX semaphores were
> > okay, but the points in that thread about pgbench not being a very
> > good test case remain relevant.
> >
> > > As far as I can tell, the sem_init(3) interface is present in the
> FreeBSD
> > > 10.3, so maybe we can use those instead?
> >
> > If that seems like a competitive alternative for you, it'd be nice to
> have
> > a platform where we use unnamed POSIX semaphores by default. I'm a
> little
> > worried about whether that code has suffered bit-rot, since it's been
> > sitting there basically unused for so long.
>
> On FreeBSD, there is no practical difference in the resource consumption
> for named vs. unnamed semaphore. I mean that after sem_open(3) call, an
> open file descriptor is not kept in the process fd table. The semaphore
> is represented by the mmaped page, libc+kernel operate solely on the
> page content and use umtx(2) to implement counted semaphore.
>
> In other words, no, there is no additional overhead of starting
> connection when using either named or unnamed (sem_init(3)) POSIX
> semaphores on FreeBSD, and there is no any open files overhead.
>
> That said, the problem with the SysV semaphores is that API allows
> operations on arbitrary sets of the semaphores. Unless some unordinary
> and complex measures are taken, implementation has to use global
> internal lock to synchronize semop(2). This is what I noted in the
> paper.
>
>