At 10:52 4/14/2003, Allison, Stephanie wrote:
>Hello -
>
>We use two device/driver support packages here at SSRL that require
>the functionality of epicsMutexLockWithTimeout which is no longer supported
>in 3.14.1. In ipac, it's only needed by the canRead diagnostic routine so I simply
>used the same logic I found in epics base/src/db/dbLock.c which does a little
>loop with try/wait. But in ether_ip, this functionality is a key part of the support.
>
>There was discussion about this in core-talk and a few sentences in the 3.14.1
>release notes, but it's not clear the best way to port from epicsMutexLockWithTimeout
>(or vxWorks semTake with a non-WAIT_FOREVER timeout) to something
>equivalent.
>
>Any suggestions? Thank you,
Hello Stephanie:
I'm wondering about a similar issue here and found that
epicsMutex has only lock(), unlock()
while epicsEvent has signal(), wait(), wait(double timeout).
My conclusion was:
use epicsMutex and hang in lock() w/o timeout in cases
where you absolutely need a resource and couldn't proceed
after a timeout, so why bother?
For thread synchronization where a wait(timeout) might well
time out in some cases, but you can print an error message
and do something else for a while, use epicsEvent.
-Kay
- Navigate by Date:
- Prev:
epicsMutexLockWithTimeout not supported in 3.14.1 Allison, Stephanie
- Next:
RE: epicsMutexLockWithTimeout not supported in 3.14.1 Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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: epicsMutexLockWithTimeout not supported in 3.14.1 Jeff Hill
- Next:
Channel Access disconnect/reconnect Nick Rees
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|