MySQL Bugs: #38477: my_pthread_setprio can change dispatch class on Solaris, not just priority

Bug #38477	my_pthread_setprio can change dispatch class on Solaris, not just priority
Submitted:	31 Jul 2008 2:11	Modified:	13 Nov 2008 3:33
Reporter:	Richard Smith	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.1.26	OS:	Solaris
Assigned to:	Davi Arnaut	CPU Architecture:	Any
Tags:	priority, pthread, solaris

Description:
my_pthread_setprio() calls pthread_setschedparam() if HAVE_PTHREAD_SETSCHEDPARAM is defined. pthread_setschedparam() on Solaris changes both a thread's priority AND its dispatch class. For changing just the priority, pthread_setschedprio() should be used. Generally its expected for a thread to inherit its dispatch class from its parent, unless explicitly changed. This occurs in 5.0.56, 5.1.26, 6.0.6, but probably applies to most MySQL releases.

How to repeat:
On Solaris, start mysqld in FX dispatch class via priocntl(1), or move it once it has started into FX dispatch class. When a user connects to mysqld, and a thread is created to service that user, the new thread is in TS dispatch class [assuming --skip-thread-priority hasn't been used to bypass the code for changing priority].

Suggested fix:
In mysys/my_pthread.c:

current:
  VOID(pthread_setschedparam(thread_id,SCHED_POLICY,&tmp_sched_param));

proposed:
  VOID(pthread_setschedprio(thread_id,prior));

Thank you for a problem report. Why do you think it is a bug, though? According to http://docs.sun.com/app/docs/doc/816-5175/pthreads-5?a=view:

"Solaris

      Only scheduling policy supported is SCHED_OTHER, which is timesharing, based on the TS scheduling class."

For me it looks like threads should belong to TS dispatch class anyway, and this is what eventually happens.

OpenSolaris/Solaris Express supports many more scheduling policies than SCHED_OTHER, and even Solaris 10 supported more than SCHED_OTHER (albeit with the restriction that you needed to be root).

Other POSIX platforms, or platforms with compatible pthreads library, may also provide alternative schedulers that somebody might want to use with MySQL. Linux for example.

Invoking the principle of "least surprise", the function should be limited to changing just the priority, or an additional parameter to my_pthread_setprio be provided. If the current behaviour is to be retained, then this side-effect should be documented in the Reference Manual.

Since MySQL uses only a few different priority levels, just one or two levels apart, the changes get swamped by the dynamic prority range of TS dispatch class on Solaris. It makes more sense to use it with FX class [although it exposes weaknesses in the current FX implemention when operating at high concurrency].

See also Bug#12702

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/56084

2664 Davi Arnaut	2008-10-11
      Bug#38477: my_pthread_setprio can change dispatch class on Solaris, not just priority
      
      The problem is that the function used by the server to increase
      the thread's priority (pthread_setschedparam) has the unintended
      side-effect of changing the calling thread scheduling policy,
      possibly overwriting a scheduling policy set by a sysadmin.
      
      The solution is to rely on the pthread_setschedprio function, if
      available, as it only changes the scheduling priority and does not
      change the scheduling policy. This function is usually available on
      Solaris and Linux, but it use won't work by default on Linux as the
      the default scheduling policy only accepts a static priority 0 -- this
      is acceptable for now as priority changing on Linux is broken anyway.

Approved over email.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/56309

2670 Davi Arnaut	2008-10-15
      Bug#38477: my_pthread_setprio can change dispatch class on Solaris, not just priority
      
      The problem is that the function used by the server to increase
      the thread's priority (pthread_setschedparam) has the unintended
      side-effect of changing the calling thread scheduling policy,
      possibly overwriting a scheduling policy set by a sysadmin.
      
      The solution is to rely on the pthread_setschedprio function, if
      available, as it only changes the scheduling priority and does not
      change the scheduling policy. This function is usually available on
      Solaris and Linux, but it use won't work by default on Linux as the
      the default scheduling policy only accepts a static priority 0 -- this
      is acceptable for now as priority changing on Linux is broken anyway.

Queued to 5.1-bugteam

Pushed into 6.0.8-alpha  (revid:davi.arnaut@sun.com-20081015222826-ecz3qpyr2iui8ejs) (version source revid:davi.arnaut@sun.com-20081016021316-p7etwjgausmhe08d) (pib:5)

Pushed into 5.1.30  (revid:davi.arnaut@sun.com-20081015222826-ecz3qpyr2iui8ejs) (version source revid:davi.arnaut@sun.com-20081015222826-ecz3qpyr2iui8ejs) (pib:5)

The versions are actually 5.1.31, 6.0.9.

Noted in 5.1.31, 6.0.9 changelog.

On Solaris, a scheduling policy applied to the main server process
could be unintentionally overwritten in client-servicing threads.

Pushed into 5.1.31-ndb-6.2.17 (revid:tomas.ulin@sun.com-20090119095303-uwwvxiibtr38djii) (version source revid:tomas.ulin@sun.com-20090108105244-8opp3i85jw0uj5ib) (merge vers: 5.1.31-ndb-6.2.17) (pib:6)

Pushed into 5.1.31-ndb-6.3.21 (revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (version source revid:tomas.ulin@sun.com-20090119104956-guxz190n2kh31fxl) (merge vers: 5.1.31-ndb-6.3.21) (pib:6)

Pushed into 5.1.31-ndb-6.4.1 (revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (version source revid:tomas.ulin@sun.com-20090119144033-4aylstx5czzz88i5) (merge vers: 5.1.31-ndb-6.4.1) (pib:6)

Pushed into 5.4.4-alpha (revid:alik@sun.com-20090916063112-8hjmu6wkxfx5qxf4) (version source revid:guilhem@mysql.com-20090708213845-36vjraclcpz7mwlq) (merge vers: 5.4.4-alpha) (pib:11)