From 29d3e89b71281c626f151a1585a40d9d2448123b Mon Sep 17 00:00:00 2001
From: rpj <rpj>
Date: Tue, 26 Apr 2005 02:41:11 +0000
Subject: ''
---
tests/Bmakefile | 8 ++--
tests/README.BENCHTESTS | 97 +++++++++++++++++++++++++++++++++++++++++++++++++
tests/README.benchtests | 97 -------------------------------------------------
tests/eyal1.c | 2 +-
4 files changed, 102 insertions(+), 102 deletions(-)
create mode 100644 tests/README.BENCHTESTS
delete mode 100644 tests/README.benchtests
(limited to 'tests')
diff --git a/tests/Bmakefile b/tests/Bmakefile
index 6ab5a34..2e3d48b 100644
--- a/tests/Bmakefile
+++ b/tests/Bmakefile
@@ -46,7 +46,7 @@ CPHDR = pthread.h semaphore.h sched.h
OPTIM = -O2
-XXLIBS = ws2_32.lib
+XXLIBS = cw32mti.lib ws2_32.lib
# C++ Exceptions
BCEFLAGS = -P -DPtW32NoCatchWarn -D__CLEANUP_CXX
@@ -85,7 +85,7 @@ PASSES= loadfree.pass \
condvar1.pass condvar1_1.pass condvar1_2.pass condvar2.pass condvar2_1.pass \
exit1.pass create1.pass create2.pass reuse1.pass reuse2.pass equal1.pass \
kill1.pass valid1.pass valid2.pass \
- exit2.pass exit3.pass exit4 exit5 \
+ exit2.pass exit3.pass exit4.pass exit5.pass \
join0.pass join1.pass join2.pass join3.pass \
mutex4.pass mutex6.pass mutex6n.pass mutex6e.pass mutex6r.pass \
mutex6s.pass mutex6es.pass mutex6rs.pass \
@@ -104,13 +104,13 @@ PASSES= loadfree.pass \
rwlock2_t.pass rwlock3_t.pass rwlock4_t.pass rwlock5_t.pass rwlock6_t.pass rwlock6_t2.pass \
context1.pass \
cancel3.pass cancel4.pass cancel5.pass cancel6a.pass cancel6d.pass \
- cancel7 cancel8 \
+ cancel7.pass cancel8.pass \
cleanup0.pass cleanup1.pass cleanup2.pass cleanup3.pass \
priority1.pass priority2.pass inherit1.pass \
spin1.pass spin2.pass spin3.pass spin4.pass \
barrier1.pass barrier2.pass barrier3.pass barrier4.pass barrier5.pass \
exception1.pass exception2.pass exception3.pass \
- cancel9 create3
+ cancel9.pass create3.pass
BENCHRESULTS = \
benchtest1.bench benchtest2.bench benchtest3.bench benchtest4.bench benchtest5.bench
diff --git a/tests/README.BENCHTESTS b/tests/README.BENCHTESTS
new file mode 100644
index 0000000..e02cb3e
--- /dev/null
+++ b/tests/README.BENCHTESTS
@@ -0,0 +1,97 @@
+
+------------
+Benchmarking
+------------
+There is a new but growing set a benchmarking programs in the
+"tests" directory. These should be runnable using the
+following command-lines corresponding to each of the possible
+library builds:
+
+MSVC:
+nmake clean VC-bench
+nmake clean VCE-bench
+nmake clean VSE-bench
+
+Mingw32:
+make clean GC-bench
+make clean GCE-bench
+
+UWIN:
+The benchtests are run as part of the testsuite.
+
+
+Mutex benchtests
+----------------
+
+benchtest1 - Lock plus unlock on an unlocked mutex.
+benchtest2 - Lock plus unlock on a locked mutex.
+benchtest3 - Trylock on a locked mutex.
+benchtest4 - Trylock plus unlock on an unlocked mutex.
+
+
+Each test times up to three alternate synchronisation
+implementations as a reference, and then times each of
+the four mutex types provided by the library. Each is
+described below:
+
+Simple Critical Section
+- uses a simple Win32 critical section. There is no
+additional overhead for this case as there is in the
+remaining cases.
+
+POSIX mutex implemented using a Critical Section
+- The old implementation which uses runtime adaptation
+depending on the Windows variant being run on. When
+the pthreads DLL was run on WinNT or higher then
+POSIX mutexes would use Win32 Critical Sections.
+
+POSIX mutex implemented using a Win32 Mutex
+- The old implementation which uses runtime adaptation
+depending on the Windows variant being run on. When
+the pthreads DLL was run on Win9x then POSIX mutexes
+would use Win32 Mutexes (because TryEnterCriticalSection
+is not implemented on Win9x).
+
+PTHREAD_MUTEX_DEFAULT
+PTHREAD_MUTEX_NORMAL
+PTHREAD_MUTEX_ERRORCHECK
+PTHREAD_MUTEX_RECURSIVE
+- The current implementation supports these mutex types.
+The underlying basis of POSIX mutexes is now the same
+irrespective of the Windows variant, and should therefore
+have consistent performance.
+
+
+In all benchtests, the operation is repeated a large
+number of times and an average is calculated. Loop
+overhead is measured and subtracted from all test times.
+
+Comment on the results
+----------------------
+The gain in performance for Win9x systems is enormous - up to
+40 times faster for unlocked mutexes (2 times faster for locked
+mutexes).
+
+Pthread_mutex_trylock also appears to be faster for locked mutexes.
+
+The price for the new consistency between WinNT and Win9x is
+slower performance (up to twice as long) across a lock/unlock
+sequence. It is difficult to get a good split timing for lock
+and unlock operations, but by code inspection, it is the unlock
+operation that is slowing the pair down in comparison with the
+old-style CS mutexes, even for the fast PTHREAD_MUTEX_NORMAL mutex
+type with no other waiting threads. However, comparitive
+performance for operations on already locked mutexes is very close.
+
+When this is translated to real-world applications, the overall
+camparitive performance should be almost identical on NT class
+systems. That is, applications with heavy mutex contention should
+have almost equal performance, while applications with only light
+mutex contention should also have almost equal performance because
+the most critical operation in this case is the lock operation.
+
+Overall, the newer pthreads-win32 mutex routines are only slower
+(on NT class systems) where and when it is least critical.
+
+Thanks go to Thomas Pfaff for the current implementation of mutex
+routines.
diff --git a/tests/README.benchtests b/tests/README.benchtests
deleted file mode 100644
index e02cb3e..0000000
--- a/tests/README.benchtests
+++ /dev/null
@@ -1,97 +0,0 @@
-
-------------
-Benchmarking
-------------
-There is a new but growing set a benchmarking programs in the
-"tests" directory. These should be runnable using the
-following command-lines corresponding to each of the possible
-library builds:
-
-MSVC:
-nmake clean VC-bench
-nmake clean VCE-bench
-nmake clean VSE-bench
-
-Mingw32:
-make clean GC-bench
-make clean GCE-bench
-
-UWIN:
-The benchtests are run as part of the testsuite.
-
-
-Mutex benchtests
-----------------
-
-benchtest1 - Lock plus unlock on an unlocked mutex.
-benchtest2 - Lock plus unlock on a locked mutex.
-benchtest3 - Trylock on a locked mutex.
-benchtest4 - Trylock plus unlock on an unlocked mutex.
-
-
-Each test times up to three alternate synchronisation
-implementations as a reference, and then times each of
-the four mutex types provided by the library. Each is
-described below:
-
-Simple Critical Section
-- uses a simple Win32 critical section. There is no
-additional overhead for this case as there is in the
-remaining cases.
-
-POSIX mutex implemented using a Critical Section
-- The old implementation which uses runtime adaptation
-depending on the Windows variant being run on. When
-the pthreads DLL was run on WinNT or higher then
-POSIX mutexes would use Win32 Critical Sections.
-
-POSIX mutex implemented using a Win32 Mutex
-- The old implementation which uses runtime adaptation
-depending on the Windows variant being run on. When
-the pthreads DLL was run on Win9x then POSIX mutexes
-would use Win32 Mutexes (because TryEnterCriticalSection
-is not implemented on Win9x).
-
-PTHREAD_MUTEX_DEFAULT
-PTHREAD_MUTEX_NORMAL
-PTHREAD_MUTEX_ERRORCHECK
-PTHREAD_MUTEX_RECURSIVE
-- The current implementation supports these mutex types.
-The underlying basis of POSIX mutexes is now the same
-irrespective of the Windows variant, and should therefore
-have consistent performance.
-
-
-In all benchtests, the operation is repeated a large
-number of times and an average is calculated. Loop
-overhead is measured and subtracted from all test times.
-
-Comment on the results
-----------------------
-The gain in performance for Win9x systems is enormous - up to
-40 times faster for unlocked mutexes (2 times faster for locked
-mutexes).
-
-Pthread_mutex_trylock also appears to be faster for locked mutexes.
-
-The price for the new consistency between WinNT and Win9x is
-slower performance (up to twice as long) across a lock/unlock
-sequence. It is difficult to get a good split timing for lock
-and unlock operations, but by code inspection, it is the unlock
-operation that is slowing the pair down in comparison with the
-old-style CS mutexes, even for the fast PTHREAD_MUTEX_NORMAL mutex
-type with no other waiting threads. However, comparitive
-performance for operations on already locked mutexes is very close.
-
-When this is translated to real-world applications, the overall
-camparitive performance should be almost identical on NT class
-systems. That is, applications with heavy mutex contention should
-have almost equal performance, while applications with only light
-mutex contention should also have almost equal performance because
-the most critical operation in this case is the lock operation.
-
-Overall, the newer pthreads-win32 mutex routines are only slower
-(on NT class systems) where and when it is least critical.
-
-Thanks go to Thomas Pfaff for the current implementation of mutex
-routines.
diff --git a/tests/eyal1.c b/tests/eyal1.c
index 31226b0..72b5697 100644
--- a/tests/eyal1.c
+++ b/tests/eyal1.c
@@ -294,7 +294,7 @@ main (int argc, char *argv[])
assert((tcs[i].stat =
pthread_create (&tcs[i].thread,
NULL,
- (void *(*)(void *))&print_server,
+ (void *(*)(void *))print_server,
(void *) &tcs[i])
) == 0);
--
cgit v1.2.3