You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@apache.org on 2002/12/30 00:03:42 UTC
Re: cvs commit: apr/test testatomic.c
On 29 Dec 2002 wrowe@apache.org wrote:
> wrowe 2002/12/29 14:45:12
>
> Modified: test testatomic.c
> Log:
> No pthread_setconcurrency here on Darwin.
>
> Revision Changes Path
> 1.22 +1 -1 apr/test/testatomic.c
>
> Index: testatomic.c
> ===================================================================
> RCS file: /home/cvs/apr/test/testatomic.c,v
> retrieving revision 1.21
> retrieving revision 1.22
> diff -u -r1.21 -r1.22
> --- testatomic.c 6 Dec 2002 17:19:17 -0000 1.21
> +++ testatomic.c 29 Dec 2002 22:45:12 -0000 1.22
> @@ -265,7 +265,7 @@
> }
>
> printf("APR Atomic Test\n===============\n\n");
> -#if !(defined WIN32) && !(defined NETWARE) && !(defined __MVS__)
> +#if !(defined WIN32) && !(defined NETWARE) && !(defined __MVS__) && !(defined DARWIN)
> pthread_setconcurrency(8);
> #endif
> printf("%-60s", "Initializing the context");
This highlights another problem with our test suite. We can't have
platform checks in our tests. Having these checks completely invalidates
the usefulness of APR. These kinds of checks are the biggest reason that
I haven't migrated testatomic to the new suite. I haven't had the time to
figure out exactly what is going on yet.
Ryan
Re: cvs commit: apr/test testatomic.c
Posted by Justin Erenkrantz <je...@apache.org>.
--On Sunday, December 29, 2002 4:49 PM -0800 rbb@apache.org wrote:
> Why not just add a couple of apr_sleep calls for a random period of
> time. That should get the threads out of being run in serial,
> shouldn't it?
As I said in my initial message, we tried that before and that
doesn't work. You have to create enough activity/load then hit the
balancing points at which point the user-space scheduler will
migrate/create new kernel threads only if the activity exceeds some
internal threshold. We could never quite figure out the right
combination of tactics to get it to work reliably. (This was even
with reading the relevant Solaris source code.) -- justin
Re: cvs commit: apr/test testatomic.c
Posted by rb...@apache.org.
Why not just add a couple of apr_sleep calls for a random period of time.
That should get the threads out of being run in serial, shouldn't it?
Ryan
On Sun, 29 Dec 2002, Justin Erenkrantz wrote:
> --On Sunday, December 29, 2002 3:03 PM -0800 rbb@apache.org wrote:
>
> > This highlights another problem with our test suite. We can't have
> > platform checks in our tests. Having these checks completely
> > invalidates the usefulness of APR. These kinds of checks are the
> > biggest reason that I haven't migrated testatomic to the new suite.
> > I haven't had the time to figure out exactly what is going on yet.
>
> Well, in this particular case, we have to go to some extremes to
> force certain schedulers (Solaris with LWPs) to actually go in
> parallel. If that call isn't there, Solaris will execute all threads
> in serial. When that happens, it invalidates the testatomic test,
> since we're explicitly trying to cause race conditions.
>
> This is a side-effect of the Solaris scheduler rebalancing only on
> cancellation points (i.e. where the thread might block). The
> testatomic code never hits a cancellation point, but normal
> applications tend to do that. While I don't know what AIX's M:N
> thread library does, it wouldn't shock me if it has the same quirk.
> Solaris's N:N thread library (i.e. what Solaris 9 uses by default)
> shouldn't have this quirk.
>
> I believe pthread_setconcurrency shouldn't be added to APR (in the
> past, Aaron and I have discussed this at length on this list), but
> its use should be allowed in the test suite because we have to
> provide hints because we're not a real program. A real program would
> be extremely hard-pressed to create code that never hits a
> cancellation point.
>
> I believe we might be able to rewrite testatomic to use condition
> variables (don't believe we had them when we wrote testatomic
> initially), but I'm still not sure if that will get around the
> concurrency problem (do a wakeup_all and hope the scheduler allocates
> enough kernel threads for all the available userspace threads). And,
> doing a sleep() or sched_yield() doesn't help either as we have to
> get all of the user threads active at the same time. The only
> solution that consistently works is to use pthread_setconcurrency.
>
> Try as you might, APR can not escape the quirks of the native OS.
> This is one particular case. -- justin
>
Re: cvs commit: apr/test testatomic.c
Posted by Justin Erenkrantz <je...@apache.org>.
--On Sunday, December 29, 2002 3:03 PM -0800 rbb@apache.org wrote:
> This highlights another problem with our test suite. We can't have
> platform checks in our tests. Having these checks completely
> invalidates the usefulness of APR. These kinds of checks are the
> biggest reason that I haven't migrated testatomic to the new suite.
> I haven't had the time to figure out exactly what is going on yet.
Well, in this particular case, we have to go to some extremes to
force certain schedulers (Solaris with LWPs) to actually go in
parallel. If that call isn't there, Solaris will execute all threads
in serial. When that happens, it invalidates the testatomic test,
since we're explicitly trying to cause race conditions.
This is a side-effect of the Solaris scheduler rebalancing only on
cancellation points (i.e. where the thread might block). The
testatomic code never hits a cancellation point, but normal
applications tend to do that. While I don't know what AIX's M:N
thread library does, it wouldn't shock me if it has the same quirk.
Solaris's N:N thread library (i.e. what Solaris 9 uses by default)
shouldn't have this quirk.
I believe pthread_setconcurrency shouldn't be added to APR (in the
past, Aaron and I have discussed this at length on this list), but
its use should be allowed in the test suite because we have to
provide hints because we're not a real program. A real program would
be extremely hard-pressed to create code that never hits a
cancellation point.
I believe we might be able to rewrite testatomic to use condition
variables (don't believe we had them when we wrote testatomic
initially), but I'm still not sure if that will get around the
concurrency problem (do a wakeup_all and hope the scheduler allocates
enough kernel threads for all the available userspace threads). And,
doing a sleep() or sched_yield() doesn't help either as we have to
get all of the user threads active at the same time. The only
solution that consistently works is to use pthread_setconcurrency.
Try as you might, APR can not escape the quirks of the native OS.
This is one particular case. -- justin