kern/43887: abnormal CPU useage when use pthread_mutex
Dorr H. Clark
dclark at applmath.scu.edu
Wed May 28 11:40:13 PDT 2003
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
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
In FreeBSD, the pthread implementation is as a user-level thread
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
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
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.
More information about the freebsd-bugs