Problem with threading on Solaris
Lionel Ulmer
I have some problem with multi-threading in Python on the Solaris platform.
My sample program (available on request :-) ) shows that when I create two
concurrent threads, the second one ONLY starts when the first one finished
(except if I add some things like a sleep or a select to do explicit task
switching).
To test, I rebuilt Python forcing the use of Solaris Thread instead of POSIX
Threads.... And this version of Python works as expected (ie 'concurrent'
running of both threads).
So I wonder if :
= it's a bug in Solaris' pthread library
= it's Python that is not using PThread properly on the Solaris platform
Anyone on different version of Solaris could try if they also have the
problem ? If yes, I would suggest using by default Solaris threads on
Solaris rather than the common PThread code.
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer
>So I wonder if :
> = it's a bug in Solaris' pthread library
> = it's Python that is not using PThread properly on the Solaris platform
Just to follow-up on myself, I just did some tests with pthread on my
Solaris box. And to have what I feel to be the 'correct' behaviour on
pthread, you need to do that :
pthread_attr_init(&attr)
pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)
And use these attributes at thread creation.
With these options, the thread are running 'concurrently'. Now, I did not
see anywhere on Python documentations what the scheduling model is for
threads... But as I did NOT see any way to :
1) set the thread priority
2) do a 'yield'
I thought that the way it was planned to work was to 'round-robin' through
the different threads (ie shcedule them as Unix processes are scheduled).
For information, my Solaris version :
SunOS herzum 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-5_10
Tim Peters
flavor of Solaris]
Solaris people have reported that often; the usual workaround seems to be to
sprinkle their code with time.sleep(0.1) (or other small values).
> ...
> Just to follow-up on myself, I just did some tests with pthread on my
> Solaris box. And to have what I feel to be the 'correct' behaviour on
> pthread, you need to do that :
>
> pthread_attr_init(&attr)
> pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)
>
> And use these attributes at thread creation.
Cool! If you're sure this will work under all Solaris releases, please
submit a Solaris patch to SourceForge (you can't assume this won't harm
other platforms -- or even compile on other platforms -- and it needs to be
#ifdef'ed by the version of pthreads in use too, since PTHREAD_SCOPE_SYSTEM
didn't always exist).
> With these options, the thread are running 'concurrently'. Now, I did
> not see anywhere on Python documentations what the scheduling model is
> for threads...
Python isn't an operating system: it doesn't schedule threads. That's
entirely up to whatever thread package you use.
> ...
> I thought that the way it was planned to work was to 'round-robin'
> through the different threads (ie shcedule them as Unix processes are
> scheduled).
Python's global interpreter lock (GIL) prevents more than one thread running
concurrently *in* the PVM, and every N bytecodes gives a different thread a
*chance* to run by releasing the GIL (so another thread can acquire it).
Whether a different thread actually gets control then isn't Python's
decision. For whatever reason on Solaris (I guess you'd have to ask Sun),
their default pthreads behavior is extremely reluctant to switch threads.
OTOH, Windows is very eager to switch threads. And so on -- YMMV.
Lionel Ulmer
>Solaris people have reported that often; the usual workaround seems to be to
>sprinkle their code with time.sleep(0.1) (or other small values).
Yup, but it's really a pain to do that... Slows things down :-)
>Cool! If you're sure this will work under all Solaris releases, please
>submit a Solaris patch to SourceForge (you can't assume this won't harm
>other platforms -- or even compile on other platforms -- and it needs to be
>#ifdef'ed by the version of pthreads in use too, since PTHREAD_SCOPE_SYSTEM
>didn't always exist).
I will see what I can do on monday (the only solaris box I have access is at
work).
But what option is best : add a Solaris-specific option in thread_pthread.h
or use thread_solaris.h on Solaris even when pthread is present ? I somewhat
prefer the Solaris thread option, it will have less chance to break POSIX
thread compilation on other Unices.
>Python isn't an operating system: it doesn't schedule threads. That's
>entirely up to whatever thread package you use.
Yes, I know... But one could have imagined that (by using some black magic
:-) ), Python thread would have been time-sliced on all OSes (and thus
preventing people to need to add 'sleep' commands in their code even when
not needed).
>For whatever reason on Solaris (I guess you'd have to ask Sun),
>their default pthreads behavior is extremely reluctant to switch threads.
>OTOH, Windows is very eager to switch threads. And so on -- YMMV.
Yes, I find this behaviour somewhat strange... What is even stranger, is
that Solaris threads do NOT exhibit this behaviour (so I wonder why they
choose 'PTHREAD_SCOPE_PROCESS' as the default behaviour for the pthreads).
Lionel
Martin von Loewis
> But what option is best : add a Solaris-specific option in thread_pthread.h
> or use thread_solaris.h on Solaris even when pthread is present ? I somewhat
> prefer the Solaris thread option, it will have less chance to break POSIX
> thread compilation on other Unices.
Don't use Solaris threads unless the configuring user explicitly asks
for it; they are broken in various ways, and POSIX threads are the way
to go.
Also, pthread_attr_setscope is part of Single Unix, so there is a good
chance that it is available on many Unix implementations. If
available, support for either contention scope is optional, so an
autoconf test may be required to find out whether PTHREAD_SCOPE_SYSTEM
is available. If it is, Python should probably use it.
> >For whatever reason on Solaris (I guess you'd have to ask Sun),
> >their default pthreads behavior is extremely reluctant to switch threads.
> >OTOH, Windows is very eager to switch threads. And so on -- YMMV.
>
> Yes, I find this behaviour somewhat strange... What is even stranger, is
> that Solaris threads do NOT exhibit this behaviour (so I wonder why they
> choose 'PTHREAD_SCOPE_PROCESS' as the default behaviour for the pthreads).
PTHREAD_SCOPE_PROCESS is less resource intensive, and it honors the
pthread thread priorities (PTHREAD_SCOPE_SYSTEM doesn't). It creates
an LWP (kernel thread) only when needed, in some cases only one per
process. pthread_setconcurrency(3) phrases this as
By default, the threads implementation ensures that a sufficient
number of threads are active so that the process can continue to
make progress. While this conserves system resources, it may not
produce the most effective level of concurrency.
With PTHREAD_SCOPE_PROCESS, you may have "unbound" threads,
i.e. threads that are ready to run but won't be scheduled by the
OS. In this contention scope, a thread will give up its LWP only
- if it performs a blocking call
- if it terminates
- if it yields explicitly (pthread_yield)
- if a preempted thread with higher priority becomes runnable
This is where the priorities come into play. With
PTHREAD_SCOPE_SYSTEM, each thread gets its own LWP, and scheduling is
entirely done through the operating system, ignoring thread priorities
(unless you run in a realtime class).
http://www.itworld.com/Comp/2375/swol-0901-insidesolaris/
has a good introduction into all that.
So in short, I recommend to find some proper autoconf magic, and then
use PTHREAD_SCOPE_SYSTEM whereever available. Perhaps a plain #ifdef
will do; it may be that PTHREAD_SCOPE_SYSTEM is required to be a
macro. If it is defined, then I bet pthread_attr_setscope is available
as well, so no need to test for that. Furthermore, if
PTHREAD_SCOPE_SYSTEM is defined but not supported, no problem either:
If it fails at run-time, it just fails, no corrective action needed.
Please don't try to make patch specific to Solaris if it has a chance
to do good to other systems as well.
Regards,
Martin
Lionel Ulmer
<loe...@informatik.hu-berlin.de> wrote:
>Also, pthread_attr_setscope is part of Single Unix, so there is a good
>chance that it is available on many Unix implementations. If
>available, support for either contention scope is optional, so an
>autoconf test may be required to find out whether PTHREAD_SCOPE_SYSTEM
>is available. If it is, Python should probably use it.
Ok, will try to add a configure check when 'pthread' has been found to see
if 'pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM)' compiles. If yes, I
will add this to the thread_pthread.h file.
By the way, how should I handle all the 'PY_PTHREAD_D*' mess ? In some case,
we use 'NULL' as the thread attributes, sometimes 'pthread_attr_default'. If
I do my patch as told, I will have to change all the NULL or
pthread_attr_default parameters by my own variable that will be initialized
by 'pthread_attr_init'.
Should I change this in all the D4 / D6 / D7 sections or only in the STD
section (the one used on Solaris) ?
Anyway, more news on monday when I come back to work and have access to my
Solaris workstation :-)
Lionel
PS: thanks to have applied (and improved) my telnetlib patch even if I was
completely unresponsive (I was pretty busy lately).
Martin von Loewis
> By the way, how should I handle all the 'PY_PTHREAD_D*' mess ?
I'd say ignore it. In the autoconf test, use pthread API as if you'd
have a fully standards compliant system. If that doesn't compile, it
still might if we follow the pthreads draft in use. However, since the
pthreads drafts have been long superceded, anybody using such a system
and wishing to use set_scope will need to supply a patch.
> In some case, we use 'NULL' as the thread attributes, sometimes
> 'pthread_attr_default'. If I do my patch as told, I will have to
> change all the NULL or pthread_attr_default parameters by my own
> variable that will be initialized by 'pthread_attr_init'.
If you think you can work it out, you may try, but my advise is not to.
> Should I change this in all the D4 / D6 / D7 sections or only in the STD
> section (the one used on Solaris) ?
Just change the standard section. I believe it becomes complicated
enough, if you try to continue passing NULL if no attributes are set
(i.e. neither stacksize, nor scope).
Regards,
Martin
Lionel Ulmer
<loe...@informatik.hu-berlin.de> wrote:
>> Should I change this in all the D4 / D6 / D7 sections or only in the STD
>> section (the one used on Solaris) ?
>
>Just change the standard section. I believe it becomes complicated
>enough, if you try to continue passing NULL if no attributes are set
>(i.e. neither stacksize, nor scope).
OK, patch submitted :
[ #460269 ] Improve threading on Solaris platform.