kern/43887: abnormal CPU useage when use pthread_mutex

[Dorr H. Clark]

The following reply was made to PR kern/43887; it has been noted by GNATS.

From: "Dorr H. Clark" <dclark at applmath.scu.edu>
To: freebsd-gnats-submit at FreeBSD.org, t_fisher at 163.com
Cc:  
Subject: Re: kern/43887: abnormal CPU useage when use pthread_mutex
Date: Wed, 28 May 2003 10:41:35 -0700

 This bug states that a CPU spike is evident when a small test program
 is executed.  We believe that this behavior is a side effect of 
 the FreeBSD threads implementation, and may perhaps only be 
 exhibited in small test programs or when larger programs
 match the same condition of calling usleep with values under
 1 msec at a point when no other threads are ready to run.
 
 Based on the original intent of the user, we believe 
 they should alter their test program to account for the FreeBSD
 threads implementation.
 
 In FreeBSD, the pthread implementation is as a user-level thread
 package,
 in other words, all threads execute in the context of a single process, 
 and the thread scheduler is hidden in the threaded version of libc.
 
 usleep (defined in src/lib/libc/gen/usleep.c) is a wrapper for 
 _nanosleep (src/lib/libc_r/uthread/uthread_nanosleep.c),
 which allows the thread scheduler to gain execution control.
 _thread_kern_scheduler then invokes thread_kern_poll which
 eventually resolves to the system call poll().  In the current
 threads implementation, poll() is invoked with a timeout granularity
 in the milliseconds.  Thus for short timeout values, poll returns
 almost immediately and the process spins around in the thread
 scheduler looking for somebody to run.
 
 Note if the sleep value is increased beyond the 1 ms threshold,
 then poll calls tsleep, throwing the entire process on the mercy
 of the scheduler.  In our experiments, a typical sleep time 
 was 20 msec, indicating the expiration of multiple ticks.
 
 The test program in the original bug was attempting to measure 
 the efficiency of pthread_mutex operations, but the code as written 
 will have CPU measurements dominated by the usleep call
 and the pthread internals.  A different approach is needed
 to serve the original purpose.
 
 If the 43887 behavior is intolerable, there are two possible approaches,
 either wait for a pthreads implementation on top of the kernel threads 
 in FreeBSD 5.0 or install the linuxthreads port, which simulates the
 Linux 
 way of handling threads as separate processes. 
 
 Konstantin Svist, engineer
 Dorr H. Clark, advisor
 COEN 284 - Operating Systems Case Study 
 Santa Clara University, 
 Santa Clara CA.