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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Puzzled with lockset(?) problem |
From: | "Mooney, Tim M." <[email protected]> |
To: | Dirk Zimoch <[email protected]>, EPICS <[email protected]> |
Date: | Mon, 18 Dec 2017 18:34:25 +0000 |
Hi Dirk,
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab From: [email protected] <[email protected]> on behalf of Dirk Zimoch <[email protected]>
Sent: Friday, December 15, 2017 10:02:52 AM To: EPICS Subject: Puzzled with lockset(?) problem Hi Folks,
A colleague puzzled me with a db that shows surprising behavior. An aSub record is triggered periodically though a CP input link. It looks up if it needs re-initialization (the user can press a button to request that). If yes it does an additional calculation. After processing it resets the record that requested the re-initialization. See the attached .db file. Usually when the user presses the button to re-initialize, the aSub does the additional calculation once and then goes back to normal processing. But the calculation may may take a bit too long -- longer than the rate of the CP input link monitors. In that case, the record never leaves initialization mode! I have simulated the slow calculation with the attached subroutine code which simply waits. (I know that is is a bad idea to wait in a synchronous subroutine. The original code does not wait but calculates.) I think that this is an effect of lock sets because the "mode" record is as well input being processed by a caput as well as output of the aSub record. But is this the intended behavior? The CP monitor finds the record busy (PACT=1) and arranges for re-processing when the record is done. But should not the FLNK be processed and the mode record go to 1 before the aSub runs again? Any idea how to fix this? Is it necessary to make the subroutine asynchonous? Making the links from and to "mode" CA links does not fix it. Scanning the aSub itself with ".1 second" does not show the strange behavior, it simply delays the scan thread. Puzzle for the weekend... Dirk |