From 29d3e89b71281c626f151a1585a40d9d2448123b Mon Sep 17 00:00:00 2001 From: rpj Date: Tue, 26 Apr 2005 02:41:11 +0000 Subject: '' --- Bmakefile | 6 +-- README.Borland | 9 ++-- implement.h | 2 + ptw32_InterlockedCompareExchange.c | 5 +- tests/Bmakefile | 8 ++-- tests/README.BENCHTESTS | 97 ++++++++++++++++++++++++++++++++++++++ tests/README.benchtests | 97 -------------------------------------- tests/eyal1.c | 2 +- 8 files changed, 112 insertions(+), 114 deletions(-) create mode 100644 tests/README.BENCHTESTS delete mode 100644 tests/README.benchtests diff --git a/Bmakefile b/Bmakefile index 9ceb0dc..6752b67 100644 --- a/Bmakefile +++ b/Bmakefile @@ -211,8 +211,8 @@ TSD_SRCS = \ all: clean $(DLLS) realclean: clean - if exist *.dll del *.dll - if exist *.lib del *.lib + if exist pthread*.dll del pthread*.dll + if exist pthread*.lib del pthread*.lib if exist *.stamp del *.stamp clean: @@ -238,7 +238,7 @@ install: $(DLLS) $(DLLS): $(DLL_OBJS) version.res ilink32 /Tpd /Gi c0d32x.obj $(DLL_OBJS), \ $@, ,\ - cw32mt.lib import32.lib, ,\ + cw32mti.lib import32.lib, ,\ version.res .c.obj: diff --git a/README.Borland b/README.Borland index 1694d55..a130d2b 100644 --- a/README.Borland +++ b/README.Borland @@ -43,12 +43,9 @@ pthreadVC's errno from a Borland C++-compiled host application correctly - I imagine there are other potential problems from the RTL mismatch too.) -[RPJ: There are still problems with errno under Borland and the DLL -will not pass the testsuite yet because of it. Setting and then reading -errno from within the same DLL, or the same application module is fine, -but DLL and application modules do not seem to be looking at the same -location for errno, even though they are logically running in the same -thread.] +[RPJ: Make sure you use the same RTL in both dll and application builds. +The dll and tests Bmakefiles use cw32mti.lib. Having some trouble with +memory read exceptions running the test suite using BCC55.] Best regards, Will diff --git a/implement.h b/implement.h index f92cc09..7504dd0 100644 --- a/implement.h +++ b/implement.h @@ -92,6 +92,8 @@ typedef VOID (APIENTRY *PAPCFUNC)(DWORD dwParam); #if defined(__MINGW32__) #include +#elif defined(__BORLANDC__) +#define int64_t ULONGLONG #else #define int64_t _int64 #endif diff --git a/ptw32_InterlockedCompareExchange.c b/ptw32_InterlockedCompareExchange.c index 5ffc754..0094635 100644 --- a/ptw32_InterlockedCompareExchange.c +++ b/ptw32_InterlockedCompareExchange.c @@ -75,7 +75,6 @@ ptw32_InterlockedCompareExchange (PTW32_INTERLOCKED_LPLONG location, #if defined(_MSC_VER) || defined(__WATCOMC__) || (defined(__BORLANDC__) && defined(HAVE_TASM32)) #define HAVE_INLINABLE_INTERLOCKED_CMPXCHG - { _asm { PUSH ecx @@ -86,7 +85,7 @@ ptw32_InterlockedCompareExchange (PTW32_INTERLOCKED_LPLONG location, LOCK CMPXCHG dword ptr [ecx],edx MOV dword ptr [result], eax POP edx - POP ecx + POP ecx } } else @@ -100,7 +99,7 @@ ptw32_InterlockedCompareExchange (PTW32_INTERLOCKED_LPLONG location, CMPXCHG dword ptr [ecx],edx MOV dword ptr [result], eax POP edx - POP ecx + POP ecx } } 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