This is the mail archive of the mailing list for the pthreas-win32 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_mutex_timedlock problem

Alexander Terekhov wrote:

It seem to me that the "/*******/"-if-below shall be added to the pthread_mutex_timedlock.c (after line 307).

/*******/  if (!result) {
/*******/     mx->recursive_count = 1;
/*******/     mx->ownerThread = (mx->kind != PTHREAD_MUTEX_FAST_NP
/*******/             ? pthread_self()
/*******/             : (pthread_t) PTW32_MUTEX_OWNER_ANONYMOUS);
/*******/  }
  case 2: /* abstime passed before we started to wait. */

Or am I just missing and/or misunderstanding something?

I was looking at it last night and also noticed this. I can't think of, or recall, any reason this would have been deliberately left out (the intention is explained in the comments in the code). My mistake.

The fix will be in CVS probably by the time you see this message, but it may not have been tested yet. Thanks Robert and Alexander.

As explained in the code comments, pthread_mutex_timedlock() is attempting a second grab at the lock [immediately] AFTER the timeout abstime. This is actually to simplify the code and reduce the overhead in managing the mutex's state. The way mutex state is being managed here results in the possibility of the lock being acquired as a natural consequence. The choice is then whether to keep the lock or give it up immediately. It is assumed that it's acceptible to keep the lock only because most applications assume/allow that absolute timeouts are a little fuzzy anyway. I think this would be true in nearly all cases. Is this reasonable and correct?



Sent by: pthreads-win32-owner at sources dot redhat dot com
To: pthreads-win32 at sources dot redhat dot com
cc: Subject: pthread_mutex_timedlock problem

Hello All,
I'm working on an rw-mutex and found something like a dead lock when testing timed lock functions.
To be sure, I wrote a simple test program, which hangs up, too.
after ~4 loops it's dead (on 1GHz P3, Win2k)
Here it is:

#include <windows.h>
#include <sys/timeb.h>
#include "lib/pthreads/pthread.h"
#define DELAY                   200
#define _log(what)              OutputDebugString( what )

pthread_mutex_t mut;

void * thread_proc_w( void * );

int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
int i;
pthread_t th_w[2];
pthread_mutexattr_t m;
pthread_mutexattr_init( &m );
pthread_mutexattr_settype( &m, PTHREAD_MUTEX_NORMAL ); //PTHREAD_MUTEX_RECURSIVE
pthread_mutex_init( &mut, &m );
pthread_mutexattr_destroy( &m );
for( i=0; i<2; i++ )
pthread_create( &th_w[i], NULL, thread_proc_w, (void *) i );
while( 1 )
Sleep( 1000 );
return 0;

void * thread_proc_w( void * param )
       timespec ts;
       _timeb tb;
       while( 1 ) {
               Sleep( 100 );
               while( 1 ) {
                       _ftime( &tb );
                       ts.tv_sec = DELAY/1000 + tb.time;
                       ts.tv_nsec = (DELAY%1000 + tb.millitm) * 1000000;

int ret = pthread_mutex_timedlock( &mut, &ts ); // this makes problems
if( ret == 0 )
_log( param ? "\r\nL0" : "\r\nL1" ); //I'm alive
Sleep( 500 );
_log( param ? "u0" : "u1" ); //unlocking ...
pthread_mutex_unlock( &mut );
pthread_exit( 0 );
return 0;


(values in Sleep() do matter - some values work fine)
After a few loops, the mutex 'mut' cannot be locked no more.
Does anyone have any idea what's wrong ?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]