Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Tue, 03 Dec 2002 08:07:18 -0600

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