Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: POSIX recursive mutex
From: "Jeff Hill" <johill@lanl.gov>
To: "'Marty Kraimer'" <mrk@aps.anl.gov>
Cc: "'Johnson, Andrew N.'" <anj@aps.anl.gov>, <core-talk@aps.anl.gov>
Date: Tue, 3 Dec 2002 12:08:21 -0700
In the win32 API WaitForSingleObject is a very slow call compared to
TryEnterCriticalSection() etc. The purpose of the WaitForSingleObject
call is only to receive a signal when some other thread unlocks the
epics mutex. The evidence for a speed up is as follows.

1) The epicsMutexLockWithTimeout() function is only called in two places
(two diagnostics) in base. It's unfortunate to double the overhead for
all of the thousands of other mutex calls in base so we can have a time
out in two diagnostics.

2) Within epicsMutexLockWithTimeout(), assuming that we need it, the
TryEnterCriticalSection() call only gets called if
TryEnterCriticalSection() fails because some other thread has the lock.

Jeff

> -----Original Message-----
> From: Marty Kraimer [mailto:mrk@aps.anl.gov]
> Sent: Tuesday, December 03, 2002 7:07 AM
> To: Jeff Hill
> Cc: 'Johnson, Andrew N.'; core-talk@aps.anl.gov
> Subject: Re: POSIX recursive mutex
> 
> Jeff Hill wrote:
> > With the win32 implementation of epicsMutex I solved this
> problem as
> > follows.
> 
> I am missing something. Since WaitForSingleObject accepts a
> timeout argument why
> cant  epicsMutexLockWithTimeout mjust be:
> 
> epicsMutexLockWithTimeout(epicsMutexId pSem, double timeOut )
> {
>      /* convert timeOut to tmo */
>      status = WaitForSingleObject ( pSem->os.mutex, tmo );
>      ...
> }
> 
> In any case your solution requires that WaitForSingleObject
> include a timeout
> argument.
> 
> Thus I still dont see any posix alternative to
> 
> timeleft = timeout;
> while(timeleft>0.0) {
>       if(pthread_mutex_trylock(...)==success) break;
>       epicsThreadSleep(shortTime);
>       timeleft -= shortTime;
> }
> 
> 
> Your second message was
> Jeff Hill wrote:
>  > AFAICT these are the only two places in all of base that
> call
>  > epicsMutexLockWithTimeout(). They are both associated with
> diagnostics
>  > which I presume need to timeout when a lock isn't available
> because of a
>  > system failure.
>  >
>  >
>  > D:\users\hill\epicsDvl\epics\base\src\db\dbLock.c(561):
>  >     lockSetModifyLockStatus =
>  > epicsMutexLockWithTimeout(lockSetModifyLock,5.0);
>  >
>  > D:\users\hill\epicsDvl\epics\base\src\db\dbNotify.c(395):
>  >     lockStatus = epicsMutexLockWithTimeout(notifyLock,2.0);
>  >
> 
> The first is only used when links are being dynamically
> modified. The second is
> only for diagnostics. Thus base is OK. Again my proposed
> solution does bother me
> since it could cause a lot of thread context switches.
> 
> Marty


Replies:
Re: POSIX recursive mutex Marty Kraimer
References:
Re: POSIX recursive mutex Marty Kraimer

Navigate by Date:
Prev: Re: POSIX recursive mutex Marty Kraimer
Next: Re: POSIX recursive mutex Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: POSIX recursive mutex Marty Kraimer
Next: Re: POSIX recursive mutex Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·