Project Results
What we have done so far
| Revision |
Date |
Changes |
| A |
Jun 24, 2004 |
Initial release |
Return to project homepage.
Introduction
The goal of this paper is to list (briefly) the problems that have been found in the NPTL
and which features from NPTL have been tested - and can be considered stable.
This paper is a summary for the information in the forum
and you should look there if you need more details or a more recent information.
Spotted problems
Disclaimer: One cannot expect to find ugly bugs in a library such as NPTL,
which as been in use for several years now. The most often used features, mutex locks for example,
are already stable and reliable. What we are tracking here are the minor problems which nobody
cares about -- until someone wants to use the feature.
The problems are listed in the order they were found. There is no importance ranking.
| #1 |
- Function:
- pthread_barrier_destroy()
- Description:
- The function could be called successfully while some threads were still inside the barrier.
A complete description of the problem can be found here.
- Status:
- This has been corrected in NPTL since Feb 20, 2004.
|
| | |
| #2 |
- Function:
- malloc()
- Description:
- When there is no more memory left, malloc should return NULL and set
errno to ENOMEM, but instead the process is killed.
- Status:
- This is the "Out Of Memory" (oom) daemon. When system becomes short on free memory,
a process (theorically the responsible for this) is killed. This mechanism is not
quite reliable as I saw several times the wrong process being killed.
|
| | |
| #3 |
- Function:
- pthread_cond_broadcast()
- Description:
- The bug was not spotted inside the project, but we found a possible
execution path leading to a hang. This is due to the FUTEX_REQUEUE usage.
- Status:
- Should have been corrected in NPTL CVS main branch ~ mid june 2004.
|
| | |
| #4 |
- Function:
- sysconf()
- Description:
- The returned value for _SC_TIMERS and _SC_THREAD_PROCESS_SHARED was 1,
when 200112 is expected.
- Status:
- Those values were corrected in NPTL ~ end of May 2004.
Need additionnal checks for other values.
|
| | |
| #5 |
- Function:
- pthread_cond_timedwait()
- Description:
- When a thread enters a wait with an absolute timeout T1 then the
clock is set to T2 > T1, the thread should be woken as if it timedout,
but it does not.
- Status:
- This non-conformance is still present in NPTL CVS -- June 24, 2004.
|
| | |
| #6 |
- Function:
- pthread_cond_timedwait()
- Description:
- When the timeout parameter is invalid (tv_nsec < 0 or >= 1^9)
the function should return EINVAL but it does not. This is not a non-conformance
as POSIX does not specify what is an invalid timeout for this function.
- Status:
- This has been reported as a defect in POSIX.
|
Conformance Tests.
Definitions:
- #TOT
- Number of assertions from POSIX for this function
- #PTS
- Number of assertions tested in PTS -- this number includes the tests from this project
- #BOS
- Number of conformance tests we wrote for this function, and which have been included in PTS
- #PTS / #TOT
- Coverage of the test suite.
- #BOS / #PTS
- Our project contribution.
| Function | #TOT | #PTS | #BOS | Link | Comments |
| pthread_mutex_init() | 10 | 10 | 5 | forum | |
| pthread_mutex_lock() | 10 | 7 | 3 | forum | Some assertions are not testable |
| pthread_mutex_unlock() | 9 | 7 | 2 | forum | Some assertions are not testable |
| pthread_cond_init() | 9 | 8 | 4 | forum | The untested assertion has no meaning for NPTL. |
| pthread_cond_timedwait() | 13 | 10 | 6 | forum | Remaining assertions are tested in stress tests. |
| pthread_cond_wait() | 8 | 1 | N/A | forum | Some assertions are partially tested in PTS but need more testing. |
| pthread_cond_signal() | 5 | 0 | N/A | forum | Some assertions are not testable, some are partially tested, some are duplicates |
Stress and Scalability Tests.
Here is a list of features tested in scalability and stress tests.
- Mutexes:
- Mutex initialization and destruction duration does not depend on the
number of mutex in use in the system -- for any type of mutex.
- Mutex initialization then destruction does not consume any system resource
(memory leak, ...) -- for any type of mutex.
- With a large amount of threads contending for some mutexes (of several types)
with pthread_mutex_lock, pthread_mutex_trylock and pthread_mutex_timedlock,
there is never more than one thread owning the same mutex at the same time.
- There is no limit on the number of threads waiting to own the same mutex.
- There is no limit on the number of different mutex having threads contending,
at the same time.
- Cond Vars:
- Condvar initialization then destruction does not consume any system resource --
for any kind of condvar.
- Condvar Initialization and destruction duration does not depend on the
number of condvars in use in the system -- for any kind of condvar.
- Latency between pthread_cond_timedwait timeout parameter and function actual return
does not depend on the number of threads waiting on the condvar -- whatever kind of condvar.
NPTL behaves very well for all those tests.
* POSIX (R) is a registered trademark of the IEEE