Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · 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:[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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System