summaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorrpj <rpj>2000-07-25 16:14:23 +0000
committerrpj <rpj>2000-07-25 16:14:23 +0000
commite2fd6e2de322cc12d9153da548ab76379049c11c (patch)
tree0e055e3496bbe45a4003d3e140e09a763d116fda /FAQ
parentb035ed05977fdef5ced4691028284b7f0ebaba19 (diff)
2000-07-25 Ross Johnson <rpj@special.ise.canberra.edu.au>
* sched.c (sched_get_priority_max): Handle different WinCE and Win32 priority values together. (sched_get_priority_min): Ditto. - Tristan Savatier <tristan@mpegtv.com> * 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 <rpj@special.ise.canberra.edu.au> * 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 <rpj@special.ise.canberra.edu.au> * FAQ: Added Q5 and Q6. tests/ChangeLog: 2000-07-25 Ross Johnson <rpj@special.ise.canberra.edu.au> * 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.
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ68
1 files changed, 68 insertions, 0 deletions
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 <sailer@ife.ee.ethz.ch>
+