Re: pthread_mutex_timedlock problem

[Ross Johnson <rpj at ise dot canberra dot edu dot au>]

Alexander Terekhov wrote:

> It seem to me that the "/*******/"-if-below shall be added to the 
> pthread_mutex_timedlock.c (after line 307).
>
>           LeaveCriticalSection(&mx->wait_cs);
> /*******/  if (!result) {
> /*******/     mx->recursive_count = 1;
> /*******/     mx->ownerThread = (mx->kind != PTHREAD_MUTEX_FAST_NP
> /*******/             ? pthread_self()
> /*******/             : (pthread_t) PTW32_MUTEX_OWNER_ANONYMOUS);
> /*******/  }
>           break;
>   }
>   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.

Question:
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?

Ross

> regards,
> alexander.
>
> 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 )
>                                break;
>                }
>                _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 ?
>
> Thanks,
>
> Robo
>