You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Yann Ylavic <yl...@gmail.com> on 2017/04/01 09:07:39 UTC
Re: Default Linux mutex method
On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> So almost two decades later, this is still odd.
>
> apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
> apr.h:#define APR_USE_SHMEM_MMAP_SHM 0
> apr.h:#define APR_USE_SHMEM_MMAP_ZERO 0
> apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0
> apr.h:#define APR_USE_SHMEM_SHMGET 1
> apr.h:#define APR_USE_SHMEM_MMAP_ANON 1
> apr.h:#define APR_USE_SHMEM_BEOS 0
> apr.h:#define APR_USE_FLOCK_SERIALIZE 0
> apr.h:#define APR_USE_SYSVSEM_SERIALIZE 1
> apr.h:#define APR_USE_POSIXSEM_SERIALIZE 0
> apr.h:#define APR_USE_FCNTL_SERIALIZE 0
> apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0
> apr.h:#define APR_USE_PTHREAD_SERIALIZE 1
What's odd?
My understanding is that SHMEM_SHMGET and MMAP_ANON are not mutually
exclusive because the former is ENOTIMPL in apr_shm_create when
filename is NULL (i.e. anonymous SHM), hence the latter would be used.
Regarding USE_SYSVSEM_SERIALIZE vs PTHREAD_SERIALIZE, the former is
for proc_mutex whereas the latter is for thread_mutex, so I think they
don't collide either.
Re: Default Linux mutex method
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Apr 3, 2017 at 9:06 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Considering the sad affair w/ pthread on OSX, I would
> recommend we stay w/ using sems.
pthread_cond_timedlock() is not really mandatory IMHO (we did not have
it in 1.5.x), and anyway it's not implemented with any other mechanism
either...
If shared pthreads are robust and have no issues with latests Linux,
BSDs (including MacOS) and Solaris, I think we should use them by
default, and fall back to the current default for older versions
(known to not work as expected) only.
Re: Default Linux mutex method
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think that "issue" is that all such options exist on all
our (modern) platforms and we don't adjust them for specific
OSs... We prefer sysv sems and pthread mutexes.
> On Apr 4, 2017, at 6:27 AM, Nick Kew <ni...@apache.org> wrote:
>
> On Tue, 2017-04-04 at 10:07 +0200, Stefan Sperling wrote:
>> For APR 1.5.2 on OpenBSD 6.0 we have this:
>> (chop)
>
> Thanks. Every little helps.
>
> Looks identical to what we've seen on Linux and MacOSX
> platforms. Have platforms converged, or has our build
> rusted away? It would be interesting to see reports
> from more diverse platforms, including non-x86-based.
>
> Is anyone thinking of tinkering with this on a timescale
> for 1.6.0? If so, please make it a config option and
> default to existing options, on ain't-broke-don't-fix
> principles.
>
> --
> Nick Kew
>
Re: Default Linux mutex method
Posted by Nick Kew <ni...@apache.org>.
On Tue, 2017-04-04 at 10:07 +0200, Stefan Sperling wrote:
> For APR 1.5.2 on OpenBSD 6.0 we have this:
> (chop)
Thanks. Every little helps.
Looks identical to what we've seen on Linux and MacOSX
platforms. Have platforms converged, or has our build
rusted away? It would be interesting to see reports
from more diverse platforms, including non-x86-based.
Is anyone thinking of tinkering with this on a timescale
for 1.6.0? If so, please make it a config option and
default to existing options, on ain't-broke-don't-fix
principles.
--
Nick Kew
Re: Default Linux mutex method
Posted by Stefan Sperling <st...@stsp.name>.
On Mon, Apr 03, 2017 at 05:36:02PM -0500, William A Rowe Jr wrote:
> On Mon, Apr 3, 2017 at 5:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> > On Mon, Apr 3, 2017 at 9:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> >> Given that we didn't elect PROC_PTHREAD mutexes as an alternate
> >> _USE_ schema, I don't have a strong opinion about changing this
> >> for 1.6.0. It can be overridden by the implementer.
> >
> > Yes, ./configure apr_lock_method=USE_PROC_PTHREAD_SERIALIZE works.
> >
> >> It seems we really
> >> should change it on trunk and get that tested in the wild by fellow devs,
> >> at least.
> >
> > I can live with this too :)
>
> For completeness, FC25's default after their patches;
>
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_TMP 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_SHM 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_ZERO 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_SHMGET_ANON 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_SHMGET 1
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_ANON 1
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_BEOS 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_FLOCK_SERIALIZE 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_SYSVSEM_SERIALIZE 1
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_POSIXSEM_SERIALIZE 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_FCNTL_SERIALIZE 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0
> /usr/include/apr-1/apr-x86_64.h:#define APR_USE_PTHREAD_SERIALIZE 1
>
> So RH hasn't seen fit to override the default. Feel free to compare to your
> $favorite_distro.
For APR 1.5.2 on OpenBSD 6.0 we have this:
#define APR_USE_SHMEM_MMAP_TMP 0
#define APR_USE_SHMEM_MMAP_SHM 0
#define APR_USE_SHMEM_MMAP_ZERO 0
#define APR_USE_SHMEM_SHMGET_ANON 0
#define APR_USE_SHMEM_SHMGET 1
#define APR_USE_SHMEM_MMAP_ANON 1
#define APR_USE_SHMEM_BEOS 0
#define APR_USE_FLOCK_SERIALIZE 0
#define APR_USE_SYSVSEM_SERIALIZE 1
#define APR_USE_POSIXSEM_SERIALIZE 0
#define APR_USE_FCNTL_SERIALIZE 0
#define APR_USE_PROC_PTHREAD_SERIALIZE 0
#define APR_USE_PTHREAD_SERIALIZE 1
The pthread functions pthread_cond_timedwait() and pthread_mutex_timedlock()
mentioned earlier in this discussion both exist.
Once the defaults are changed on APR trunk, I can test APR trunk on
OpenBSD 6.0 (and 6.1, due for release May 1).
If anything is missing I can poke OpenBSD developers who are working
on pthreads and try to get them to add interfaces APR needs.
I can't say anything about other BSDs, I'm afraid. I don't have
the time to keep up with all of them.
Re: Default Linux mutex method
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Apr 3, 2017 at 5:00 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Mon, Apr 3, 2017 at 9:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>> Given that we didn't elect PROC_PTHREAD mutexes as an alternate
>> _USE_ schema, I don't have a strong opinion about changing this
>> for 1.6.0. It can be overridden by the implementer.
>
> Yes, ./configure apr_lock_method=USE_PROC_PTHREAD_SERIALIZE works.
>
>> It seems we really
>> should change it on trunk and get that tested in the wild by fellow devs,
>> at least.
>
> I can live with this too :)
For completeness, FC25's default after their patches;
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_TMP 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_SHM 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_ZERO 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_SHMGET_ANON 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_SHMGET 1
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_MMAP_ANON 1
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SHMEM_BEOS 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_FLOCK_SERIALIZE 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_SYSVSEM_SERIALIZE 1
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_POSIXSEM_SERIALIZE 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_FCNTL_SERIALIZE 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0
/usr/include/apr-1/apr-x86_64.h:#define APR_USE_PTHREAD_SERIALIZE 1
So RH hasn't seen fit to override the default. Feel free to compare to your
$favorite_distro.
Re: Default Linux mutex method
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Apr 3, 2017 at 9:24 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> Given that we didn't elect PROC_PTHREAD mutexes as an alternate
> _USE_ schema, I don't have a strong opinion about changing this
> for 1.6.0. It can be overridden by the implementer.
Yes, ./configure apr_lock_method=USE_PROC_PTHREAD_SERIALIZE works.
> It seems we really
> should change it on trunk and get that tested in the wild by fellow devs,
> at least.
I can live with this too :)
Re: Default Linux mutex method
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Apr 3, 2017 at 2:06 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Considering the sad affair w/ pthread on OSX, I would
> recommend we stay w/ using sems.
For darwin (and other BSD? or do they still fcntl?), agreed 100%.
Linux seems to be in a completely different state of affairs. Unless I'm
confusing proc mutexes with thread mutexes again, pthread locks are
the one-and-only implementation now with OpenSSL 1.1.0 (the user-
replaceable locking callbacks are now no-ops / never invoked.) They
don't have timed mutexes I'm aware of, so that additional headache
isn't part of their puzzle. But it's a good endorsement for a change on
Linux, at least.
Given that we didn't elect PROC_PTHREAD mutexes as an alternate
_USE_ schema, I don't have a strong opinion about changing this
for 1.6.0. It can be overridden by the implementer. It seems we really
should change it on trunk and get that tested in the wild by fellow devs,
at least.
Re: Default Linux mutex method
Posted by Jim Jagielski <ji...@jaguNET.com>.
Considering the sad affair w/ pthread on OSX, I would
recommend we stay w/ using sems.
Re: Default Linux mutex method
Posted by Jim Jagielski <ji...@jaguNET.com>.
Of course, it depends on the number of threads, natch...
> On Apr 3, 2017, at 2:07 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> Using:
>
> https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c
>
> under OSX/macOS, pthread_mutex_lock is much quicker. Which makes
> sense since sysv sems and posix sems do much more than simply
> "lock"
Re: Default Linux mutex method
Posted by Jim Jagielski <ji...@jaguNET.com>.
Using:
https://github.com/jimjag/benchmarks/blob/master/lock/lock_test.c
under OSX/macOS, pthread_mutex_lock is much quicker. Which makes
sense since sysv sems and posix sems do much more than simply
"lock"
Re: Default Linux mutex method
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Mon, Apr 3, 2017 at 5:05 AM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Yes I got this, my point is that there are no duplicates here, one and
> only one per:
> - pthread mutex => PTHREAD_SERIALIZE (kind of implicit since all
> unixes use pthreads, but not to be confused with
> PROC_PTHREAD_SERIALIZE...).
Herp derp... yup that was the error I made.
So the remaining question - whether it would be good to swap SYSVSEM
with PROC_PTHREAD on linux - should be based on more study, Jim's
performance question first and foremost, and also observations about
similar projects and the intrinsic flaw of lingering semaphores after abend.
It may be worthwhile to note that my default FC25 box has zero sysv
semaphores during normal operation, which suggests it is greatly avoided.
Re: Default Linux mutex method
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Apr 3, 2017 at 6:16 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Apr 1, 2017 4:07 AM, "Yann Ylavic" <yl...@gmail.com> wrote:
>
> On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>> So almost two decades later, this is still odd.
>>
>> apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
>> apr.h:#define APR_USE_SHMEM_MMAP_SHM 0
>> apr.h:#define APR_USE_SHMEM_MMAP_ZERO 0
>> apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0
>> apr.h:#define APR_USE_SHMEM_SHMGET 1
>> apr.h:#define APR_USE_SHMEM_MMAP_ANON 1
>> apr.h:#define APR_USE_SHMEM_BEOS 0
>> apr.h:#define APR_USE_FLOCK_SERIALIZE 0
>> apr.h:#define APR_USE_SYSVSEM_SERIALIZE 1
>> apr.h:#define APR_USE_POSIXSEM_SERIALIZE 0
>> apr.h:#define APR_USE_FCNTL_SERIALIZE 0
>> apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0
>> apr.h:#define APR_USE_PTHREAD_SERIALIZE 1
>
> What's odd?
>
>
>
> APR_HAS_ describes support of a feature/mechanism.
>
> APR_USE_ was an imperitive. The presence, in this case of multiple multiples
> indicates broken autoconf logic.
Yes I got this, my point is that there are no duplicates here, one and
only one per:
- named based SHM => SHMEM_SHMGET,
- anonymous SHM => MMAP_ANON,
- proc mutex => SYSVSEM_SERIALIZE,
- pthread mutex => PTHREAD_SERIALIZE (kind of implicit since all
unixes use pthreads, but not to be confused with
PROC_PTHREAD_SERIALIZE...).
Re: Default Linux mutex method
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Apr 1, 2017 4:07 AM, "Yann Ylavic" <yl...@gmail.com> wrote:
On Fri, Mar 31, 2017 at 4:21 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> So almost two decades later, this is still odd.
>
> apr.h:#define APR_USE_SHMEM_MMAP_TMP 0
> apr.h:#define APR_USE_SHMEM_MMAP_SHM 0
> apr.h:#define APR_USE_SHMEM_MMAP_ZERO 0
> apr.h:#define APR_USE_SHMEM_SHMGET_ANON 0
> apr.h:#define APR_USE_SHMEM_SHMGET 1
> apr.h:#define APR_USE_SHMEM_MMAP_ANON 1
> apr.h:#define APR_USE_SHMEM_BEOS 0
> apr.h:#define APR_USE_FLOCK_SERIALIZE 0
> apr.h:#define APR_USE_SYSVSEM_SERIALIZE 1
> apr.h:#define APR_USE_POSIXSEM_SERIALIZE 0
> apr.h:#define APR_USE_FCNTL_SERIALIZE 0
> apr.h:#define APR_USE_PROC_PTHREAD_SERIALIZE 0
> apr.h:#define APR_USE_PTHREAD_SERIALIZE 1
What's odd?
APR_HAS_ describes support of a feature/mechanism.
APR_USE_ was an imperitive. The presence, in this case of multiple
multiples indicates broken autoconf logic.