You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/06/30 21:57:33 UTC
[PATCH] Allow pthread_mutex_t to be a cross-process lock
Can someone enlighten me as to why we have --with-pthread-cross and we
aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
and pthread_mutexattr_setpshared, it seems reasonable enough to
define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
suitable for cross-process locks for some other reason that we have to
have a manual override?
Unless someone says otherwise, I'll commit this tonight/tomorrow.
-- justin
Index: configure.in
===================================================================
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.321
diff -u -r1.321 configure.in
--- configure.in 2001/06/28 01:57:02 1.321
+++ configure.in 2001/06/30 19:52:34
@@ -955,7 +955,7 @@
APR_IFALLYES(header:fcntl.h define:F_SETLK,
APR_DECIDE(USE_FCNTL_SERIALIZE, [SVR4-style fcntl()]))
APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
- func:pthread_mutexattr_setpshared custom:with_pthread_cross,
+ func:pthread_mutexattr_setpshared,
APR_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex]))
if test "x$apr_lock_method" != "x"; then
APR_DECISION_FORCE($apr_lock_method)
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Mon, Jul 02, 2001 at 08:21:10AM -0400, Jeff Trawick wrote:
> > Please don't commit just yet.
>
> Should I back this out? Ryan wants to T&R at 10AM PST. I guess the
> easy "fix" would be to place fcntl() decision AFTER the
> pthread_mutex_t support.
Definitely... HP-UX and OS/390 are now broken. The shared memory
mechanism used by the cross-process pthread mutex support doesn't work
on those systems.
> > That piece of code decides not what kind of interprocess lock
> > mechanism APR *has* support for on the platform but what kind of
> > interprocess lock mechanism APR will *use* by default.
>
> Correct, I knew that. But, as seen by the other warning that was
> triggered by this, no one actually has ever tested/maintained this code.
> Now, we can start to exercise it. =-) (Which is partly the reason why
> I was complaining about the 2.0.20 T&R taking in these changes...)
I'd say that the Apache AcceptMutex directive gives you plenty of
ability to exercise it without changing the default lock choice :)
> > I suspect that you misunderstood what that code is doing... otherwise,
> > you'd try to explain why you want to change the [usual] default
> > mechanism from fcntl() to interprocess pthread mutex.
>
> Typically, from my understanding of things, pthread mutex should be
> the option that lets us scale the best on the high-end. From what
> Bill said, this is what IBM ships with IBM HTTPD. And, on Solaris,
> you want to use pthread-related locking for best performance. Now, I
> could be wrong about this being the "best choice."
Basically, I think we changed the Apache default without a crisp
understanding of why it should change. My understanding of things is
that on Solaris and AIX the best lock choice depends on the config of
Apache and the machine. I can't tell you that fcntl is "better
overall" (whatever that means), but I don't see any info to support
the claim that pthread mutex is "better overall" either.
> What platforms are going to have pthread_mutex_t with SHARED_PROCESS
> that WORKS and not have this?
OS/390, HP-UX, dunno what else (if any)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Jul 02, 2001 at 08:21:10AM -0400, Jeff Trawick wrote:
> Please don't commit just yet.
Should I back this out? Ryan wants to T&R at 10AM PST. I guess the
easy "fix" would be to place fcntl() decision AFTER the
pthread_mutex_t support.
> That piece of code decides not what kind of interprocess lock
> mechanism APR *has* support for on the platform but what kind of
> interprocess lock mechanism APR will *use* by default.
Correct, I knew that. But, as seen by the other warning that was
triggered by this, no one actually has ever tested/maintained this code.
Now, we can start to exercise it. =-) (Which is partly the reason why
I was complaining about the 2.0.20 T&R taking in these changes...)
> I suspect that you misunderstood what that code is doing... otherwise,
> you'd try to explain why you want to change the [usual] default
> mechanism from fcntl() to interprocess pthread mutex.
Typically, from my understanding of things, pthread mutex should be
the option that lets us scale the best on the high-end. From what
Bill said, this is what IBM ships with IBM HTTPD. And, on Solaris,
you want to use pthread-related locking for best performance. Now, I
could be wrong about this being the "best choice."
> Let's back up now. What is the problem you want to solve?
>
> a) you really think we should default to interprocess pthread mutex
> whenever the platform supports it?
>
> I don't feel too comfortable with that for several reasons
>
> i) the current APR code doesn't support all platforms which have
> interprocess pthread mutex support
>
> the current logic relies on mmap-ed /dev/zero for the shared
> memory where the mutex lives; this doesn't work everywhere
>
> This should be remedied, but with your patch we go downhill on
> some platforms.
What platforms are going to have pthread_mutex_t with SHARED_PROCESS
that WORKS and not have this? By process of elimination, I'll think
we'll find that this won't be a big deal. <smirk> Yeah, we can
address that somehow. Now, we need to somehow get shmem working.
Ack.
> ii) it means we pick a different default lock depending upon
> whether or not we have thread support
Lots of things change if you have thread support or don't. IF this is
truly the better option if you are going to have threading, why not
enable it?
> iii) historically, fcntl()-based locking is something that works
> pretty darn well overall across supported platforms. There are
> platform and config-specific situations where something else is
> more appropriate, but historically it has been the safest bet
> for a system-independent default.
Yes, but is fcntl() the "best" choice? -- justin
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> Can someone enlighten me as to why we have --with-pthread-cross and we
> aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> and pthread_mutexattr_setpshared, it seems reasonable enough to
> define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> suitable for cross-process locks for some other reason that we have to
> have a manual override?
>
> Unless someone says otherwise, I'll commit this tonight/tomorrow.
Please don't commit just yet.
That piece of code decides not what kind of interprocess lock
mechanism APR *has* support for on the platform but what kind of
interprocess lock mechanism APR will *use* by default.
I suspect that you misunderstood what that code is doing... otherwise,
you'd try to explain why you want to change the [usual] default
mechanism from fcntl() to interprocess pthread mutex.
Let's back up now. What is the problem you want to solve?
a) you really think we should default to interprocess pthread mutex
whenever the platform supports it?
I don't feel too comfortable with that for several reasons
i) the current APR code doesn't support all platforms which have
interprocess pthread mutex support
the current logic relies on mmap-ed /dev/zero for the shared
memory where the mutex lives; this doesn't work everywhere
This should be remedied, but with your patch we go downhill on
some platforms.
ii) it means we pick a different default lock depending upon
whether or not we have thread support
iii) historically, fcntl()-based locking is something that works
pretty darn well overall across supported platforms. There are
platform and config-specific situations where something else is
more appropriate, but historically it has been the safest bet
for a system-independent default.
b) you don't like the way APR let's the builder tell APR "yes
indeed it is okay to use interprocess pthread mutex by default"
c) something else
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.321
> diff -u -r1.321 configure.in
> --- configure.in 2001/06/28 01:57:02 1.321
> +++ configure.in 2001/06/30 19:52:34
> @@ -955,7 +955,7 @@
> APR_IFALLYES(header:fcntl.h define:F_SETLK,
> APR_DECIDE(USE_FCNTL_SERIALIZE, [SVR4-style fcntl()]))
> APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
> - func:pthread_mutexattr_setpshared custom:with_pthread_cross,
> + func:pthread_mutexattr_setpshared,
> APR_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex]))
> if test "x$apr_lock_method" != "x"; then
> APR_DECISION_FORCE($apr_lock_method)
(Sorry for the delay... We've been moving over the last week and
things are pretty crazy.)
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Jun 30, 2001 at 01:16:43PM -0700, rbb@covalent.net wrote:
> In general, most platforms don't really support cross process pthread
> mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
> properly. For example, AIX has that defined, but they don't really
> support pthread mutex's cross processes.
Is this something that we can place in either the hints file (for those
platforms that are lying to us), or can we perform some AC_TRY_RUN test
to see whether it works. I believe that pthread_mutex_t is going to be
the best cross-process locking choice IF the platform does what it says
it does (which, I believe Solaris does). -- justin
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Bill Stoddard <bi...@wstoddard.com>.
Ooops, send this to the wrong list...
Also my bad, Apache 1.3 does NOT default to pthread serialized accept on AIX, but that's what we
ship with IBM HTTP Server and it works much better than FCNTL on 8 way machines and above.
Bill
----- Original Message -----
From: "Bill Stoddard" <bi...@wstoddard.com>
To: <ne...@apache.org>
Sent: Saturday, June 30, 2001 4:36 PM
Subject: Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
>
> > On Sat, 30 Jun 2001, Justin Erenkrantz wrote:
> >
> > > Can someone enlighten me as to why we have --with-pthread-cross and we
> > > aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> > > and pthread_mutexattr_setpshared, it seems reasonable enough to
> > > define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> > > suitable for cross-process locks for some other reason that we have to
> > > have a manual override?
> > >
> > > Unless someone says otherwise, I'll commit this tonight/tomorrow.
> >
> > In general, most platforms don't really support cross process pthread
> > mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
> > properly. For example, AIX has that defined, but they don't really
> > support pthread mutex's cross processes.
>
> PTHREAD_PROCESS_SHARED works for me on AIX 4.3.2 and later. And you will see this is the default
for
> Apache 1.3 for AIX.
>
> Are you seeing actual failures or going from memory of conversations past?
>
> Bill
>
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Jun 30, 2001 at 02:08:17PM -0700, rbb@covalent.net wrote:
> Memories of conversations with Manoj. AIX may have it working, but I
> definately remember that there are platforms with PTHREAD_PROCESS_SHARED
> defined even though it doesn't work.
FWIW, Linux's glibc has this bogus behavior (setpshared would return
ENOSYS in glibc).
Try this patch on for size. Correctly detects Solaris as being good and
Linux as being bogus. (And FreeBSD doesn't have threads anyway.)
The only thing I don't like is "int main()", but Solaris refused to
compile it without that since we have -Wall defined. -- justin
Index: configure.in
===================================================================
RCS file: /home/cvs/apr/configure.in,v
retrieving revision 1.321
diff -u -r1.321 configure.in
--- configure.in 2001/06/28 01:57:02 1.321
+++ configure.in 2001/06/30 21:46:03
@@ -937,6 +937,30 @@
if test "$threads" = "1"; then
APR_CHECK_DEFINE(PTHREAD_PROCESS_SHARED, pthread.h)
AC_CHECK_FUNCS(pthread_mutexattr_setpshared)
+ dnl Some systems have setpshared and define PROCESS_SHARED, but don't
+ dnl support PROCESS_SHARED locks. So, we must validate that we can
+ dnl go through the steps without receiving some sort of system error.
+ APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED func:pthread_mutexattr_setpshared,
+ AC_TRY_RUN([
+ #include <sys/types.h>
+ #include <pthread.h>
+ int main()
+ {
+ pthread_mutex_t mutex;
+ pthread_mutexattr_t attr;
+ if (pthread_mutexattr_init(&attr))
+ exit(1);
+ if (pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED))
+ exit(2);
+ if (pthread_mutex_init(&mutex, &attr))
+ exit(3);
+ if (pthread_mutexattr_destroy(&attr))
+ exit(4);
+ if (pthread_mutex_destroy(&mutex))
+ exit(5);
+ exit(0);
+ }], [], [ac_cv_func_pthread_mutexattr_setpshared=no],
+ [ac_cv_func_pthread_mutexattr_setpshared=no]))
fi
# See which lock mechanisms we can support on this system.
@@ -955,7 +979,7 @@
APR_IFALLYES(header:fcntl.h define:F_SETLK,
APR_DECIDE(USE_FCNTL_SERIALIZE, [SVR4-style fcntl()]))
APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
- func:pthread_mutexattr_setpshared custom:with_pthread_cross,
+ func:pthread_mutexattr_setpshared,
APR_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex]))
if test "x$apr_lock_method" != "x"; then
APR_DECISION_FORCE($apr_lock_method)
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by rb...@covalent.net.
> > > PTHREAD_PROCESS_SHARED works for me on AIX 4.3.2 and later. And you will see this is the default
> for
> > > Apache 1.3 for AIX.
> > >
> > > Are you seeing actual failures or going from memory of conversations past?
> >
> > Memories of conversations with Manoj. AIX may have it working, but I
> > definately remember that there are platforms with PTHREAD_PROCESS_SHARED
> > defined even though it doesn't work.
> >
> > Ryan
>
> AIX 4.2.1 implements pthreads draft 7 and it defines PTHREAD_PROCESS_SHARED but does not implement
> it. That's probably what your thinking of.
YES, thank you for doing the research! As it happens, Justin has a patch
that should detect that correctly. So, +1 for Justin's patch, and this
issue goes away. :-)
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Sat, 30 Jun 2001, Bill Stoddard wrote:
>
> >
> > > On Sat, 30 Jun 2001, Justin Erenkrantz wrote:
> > >
> > > > Can someone enlighten me as to why we have --with-pthread-cross and we
> > > > aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> > > > and pthread_mutexattr_setpshared, it seems reasonable enough to
> > > > define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> > > > suitable for cross-process locks for some other reason that we have to
> > > > have a manual override?
> > > >
> > > > Unless someone says otherwise, I'll commit this tonight/tomorrow.
> > >
> > > In general, most platforms don't really support cross process pthread
> > > mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
> > > properly. For example, AIX has that defined, but they don't really
> > > support pthread mutex's cross processes.
> >
> > PTHREAD_PROCESS_SHARED works for me on AIX 4.3.2 and later. And you will see this is the default
for
> > Apache 1.3 for AIX.
> >
> > Are you seeing actual failures or going from memory of conversations past?
>
> Memories of conversations with Manoj. AIX may have it working, but I
> definately remember that there are platforms with PTHREAD_PROCESS_SHARED
> defined even though it doesn't work.
>
> Ryan
AIX 4.2.1 implements pthreads draft 7 and it defines PTHREAD_PROCESS_SHARED but does not implement
it. That's probably what your thinking of.
Bill
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by rb...@covalent.net.
On Sat, 30 Jun 2001, Bill Stoddard wrote:
>
> > On Sat, 30 Jun 2001, Justin Erenkrantz wrote:
> >
> > > Can someone enlighten me as to why we have --with-pthread-cross and we
> > > aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> > > and pthread_mutexattr_setpshared, it seems reasonable enough to
> > > define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> > > suitable for cross-process locks for some other reason that we have to
> > > have a manual override?
> > >
> > > Unless someone says otherwise, I'll commit this tonight/tomorrow.
> >
> > In general, most platforms don't really support cross process pthread
> > mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
> > properly. For example, AIX has that defined, but they don't really
> > support pthread mutex's cross processes.
>
> PTHREAD_PROCESS_SHARED works for me on AIX 4.3.2 and later. And you will see this is the default for
> Apache 1.3 for AIX.
>
> Are you seeing actual failures or going from memory of conversations past?
Memories of conversations with Manoj. AIX may have it working, but I
definately remember that there are platforms with PTHREAD_PROCESS_SHARED
defined even though it doesn't work.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Sat, 30 Jun 2001, Justin Erenkrantz wrote:
>
> > Can someone enlighten me as to why we have --with-pthread-cross and we
> > aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> > and pthread_mutexattr_setpshared, it seems reasonable enough to
> > define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> > suitable for cross-process locks for some other reason that we have to
> > have a manual override?
> >
> > Unless someone says otherwise, I'll commit this tonight/tomorrow.
>
> In general, most platforms don't really support cross process pthread
> mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
> properly. For example, AIX has that defined, but they don't really
> support pthread mutex's cross processes.
PTHREAD_PROCESS_SHARED works for me on AIX 4.3.2 and later. And you will see this is the default for
Apache 1.3 for AIX.
Are you seeing actual failures or going from memory of conversations past?
Bill
Re: [PATCH] Allow pthread_mutex_t to be a cross-process lock
Posted by rb...@covalent.net.
On Sat, 30 Jun 2001, Justin Erenkrantz wrote:
> Can someone enlighten me as to why we have --with-pthread-cross and we
> aren't telling anyone? If we have pthread.h, PTHREAD_PROCESS_SHARED,
> and pthread_mutexattr_setpshared, it seems reasonable enough to
> define USE_PROC_PTHREAD_SERIALIZE to 1. Or, are pthread_mutex_t not
> suitable for cross-process locks for some other reason that we have to
> have a manual override?
>
> Unless someone says otherwise, I'll commit this tonight/tomorrow.
In general, most platforms don't really support cross process pthread
mutex's. Even those that have PTHREAD_PROCESS_SHARED tend to not work
properly. For example, AIX has that defined, but they don't really
support pthread mutex's cross processes.
Ryan
> -- justin
>
> Index: configure.in
> ===================================================================
> RCS file: /home/cvs/apr/configure.in,v
> retrieving revision 1.321
> diff -u -r1.321 configure.in
> --- configure.in 2001/06/28 01:57:02 1.321
> +++ configure.in 2001/06/30 19:52:34
> @@ -955,7 +955,7 @@
> APR_IFALLYES(header:fcntl.h define:F_SETLK,
> APR_DECIDE(USE_FCNTL_SERIALIZE, [SVR4-style fcntl()]))
> APR_IFALLYES(header:pthread.h define:PTHREAD_PROCESS_SHARED dnl
> - func:pthread_mutexattr_setpshared custom:with_pthread_cross,
> + func:pthread_mutexattr_setpshared,
> APR_DECIDE(USE_PROC_PTHREAD_SERIALIZE, [pthread mutex]))
> if test "x$apr_lock_method" != "x"; then
> APR_DECISION_FORCE($apr_lock_method)
>
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------