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:[email protected]]
> Sent: Tuesday, December 03, 2002 7:07 AM
> To: Jeff Hill
> Cc: 'Johnson, Andrew N.'; [email protected]
> 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:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: POSIX recursive mutex Marty Kraimer
- Next:
Re: POSIX recursive mutex Marty Kraimer
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|