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

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.