From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27730 invoked by alias); 4 Mar 2003 00:56:31 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 27714 invoked from network); 4 Mar 2003 00:56:31 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by 172.16.49.205 with SMTP; 4 Mar 2003 00:56:31 -0000 Received: from ise.canberra.edu.au (special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.11.6/8.11.6) with ESMTP id h240uAh25269; Tue, 4 Mar 2003 11:56:11 +1100 Message-ID: <3E63FA44.4020302@ise.canberra.edu.au> Date: Tue, 04 Mar 2003 00:56:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Terekhov CC: pthreads-win32@sources.redhat.com Subject: Re: pthread_mutex_timedlock problem References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00036.txt.bz2 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@sources.redhat.com >To: pthreads-win32@sources.redhat.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 >#include >#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 > >