From e2fd6e2de322cc12d9153da548ab76379049c11c Mon Sep 17 00:00:00 2001 From: rpj Date: Tue, 25 Jul 2000 16:14:23 +0000 Subject: 2000-07-25 Ross Johnson * sched.c (sched_get_priority_max): Handle different WinCE and Win32 priority values together. (sched_get_priority_min): Ditto. - Tristan Savatier * create.c (pthread_create): Force new threads to wait until pthread_create has the new thread's handle; we also retain a local copy of the handle for internal use until pthread_create returns. * private.c (_pthread_threadStart): Initialise ei[]. (_pthread_threadStart): When beginthread is used to start the thread, force waiting until the creator thread had the thread handle. * cancel.c (_pthread_cancel_thread): Include context switch code for defined(_X86_) environments in addition to _M_IX86. * rwlock.c (pthread_rwlock_destroy): Assignment changed to avoid compiler warning. * private.c (_pthread_get_exception_services_code): Cast NULL return value to avoid compiler warning. * cleanup.c (pthread_pop_cleanup): Initialise "cleanup" variable to avoid compiler warnings. * misc.c (_pthread_new): Change "new" variable to "t" to avoid confusion with the C++ keyword of the same name. * condvar.c (cond_wait_cleanup): Initialise lastWaiter variable. (cond_timedwait): Remove unused local variables. to avoid compiler warnings. * dll.c (dllMain): Remove 2000-07-21 change - problem appears to be in pthread_create(). 2000-07-22 Ross Johnson * tsd.c (pthread_key_create): If a destructor was given and the pthread_mutex_init failed, then would try to reference a NULL pointer (*key); eliminate this section of code by using a dynamically initialised mutex (PTHREAD_MUTEX_INITIALIZER). * tsd.c (pthread_setspecific): Return an error if unable to set the value; simplify cryptic conditional. * tsd.c (pthread_key_delete): Locking threadsLock relied on mutex_lock returning an error if the key has no destructor. ThreadsLock is only initialised if the key has a destructor. Making this mutex a static could reduce the number of mutexes used by an application since it is actually created only at first use and it's often destroyed soon after. 2000-07-22 Ross Johnson * FAQ: Added Q5 and Q6. tests/ChangeLog: 2000-07-25 Ross Johnson * runtest.bat: modified to work under W98. * runall.bat: Add new tests; modified to work under W98. It was ok under NT. * Makefile: Add new tests. * exception1.c: New; Test passing exceptions back to the application and retaining library internal exceptions. * join0.c: New; Test a single join. --- FAQ | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) (limited to 'FAQ') diff --git a/FAQ b/FAQ index 426e92c..f6da212 100644 --- a/FAQ +++ b/FAQ @@ -14,6 +14,10 @@ Q 3 How do I use pthread.dll for Win32 (Visual C++ 5.0) Q 4 Cancelation doesn't work for me, why? +Q 5 Thread won't block after two calls to mutex_lock + +Q 6 How do I generate libpthread.a for use with Mingw32? + ============================================================================= Q 1 Should I use Cygwin or Mingw32 as a development environment? @@ -253,3 +257,67 @@ a thread is going to block on a Win32 handle. These are: Regards. Ross +------------------------------------------------------------------------------ + +Q 5 Thread won't block after two calls to mutex_lock +--- + +A 5 +--- + +> i was testing this pthread for win32 in my prog. +> when i checked if it was blocking mutex_lock calls, i was surprised when it +> didnt lock +> +> pthread_mutex_t DBlock; +> +> pthread_mutex_init( &DBlock, NULL ); +> pthread_mutex_lock( &DBlock ); +> pthread_mutex_lock( &DBlock ); +> +> ^^ these two calls didnt block + +POSIX leaves the result "undefined" for a thread that tries +to recursively lock the same mutex (one that it owns already). +That means the actual semantics are left up to the +implementation, but should not be relied upon for code that +will be ported to different POSIX threads implementations. + +In the pthreads-win32 implementation a thread won't deadlock +itself by relocking the mutex. Subsequent calls to +pthread_mutex_lock() as in your example above increment +the lock count but the thread continues on. Consequently, +the thread must ensure that it unlocks the mutex once for +each lock operation. That is, pthreads-win32 mutexes are +always recursive. + +You may want to look at the other synchronisation devices +available in the library, such as condition variables or +read-write locks. + +Ross + +------------------------------------------------------------------------------ + +Q 6 How do I generate libpthread.a for use with Mingw32? +--- + +A 6 +--- + +> I'm lacking the libpthread.a that +> used to come with the pre-compiled package. The last time this +> library appeared was in 1999-08-12. Without this library I cannot +> use the pre-compiled dll. + +You can create libpthread.a from the .def file, should work along these +lines: + +$(DLLTOOL) --as $(AS) -k --dllname libpthread.dll --output-lib +libpthread.a --def $(srcdir)/libpthread.def + +Where DLLTOOL is i686-pc-cygwin-dlltool +and AS i686-pc-cygwin-as. + +Thomas Sailer + -- cgit v1.2.3