Problem with threading on Solaris

Martin von Loewis loewis at informatik.hu-berlin.de
Fri Sep 7 17:21:14 EDT 2001


bbrox at bbrox.org (Lionel Ulmer) writes:

> 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



More information about the Python-list mailing list