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: pyepics problem with PV.put(wait=True) |
From: | Matt Newville <[email protected]> |
To: | Jameson Graef Rollins <[email protected]> |
Cc: | EPICS tech-talk <[email protected]> |
Date: | Fri, 15 Aug 2014 07:42:19 -0500 |
On Thu, Aug 14 2014, Matt Newville <[email protected]> wrote:Hey, Matt (and Mark). Thank you both so much for the speedy responses.
> Sorry for the trouble. The basic issue here is that PV.get() relies (by
> default) on a callback on the monitored value to keep the PV's value
> up-to-date, avoiding explicit calls to ca.get(). The put(wait=True) or
> put-with-callback uses a *different* callback on the put() request. When
> the put-callback completes, the callback for the monitored value may not
> have been run.
I suspected I was seeing the race condition that you both describe.
Yeah, if that was possible I think that might best jive with
> It's reasonable to say that when the put-with-wait completes that the
> cached value should be updated. I'll look into that.
expectations. Thanks for looking into it.
I think this is probably the solution I'm looking for, although I need
> The alternative is to:
> for i in range(10):
> pv.put(i, wait=True)
> print pv.get(auto_monitor=False)
>
> which will make an explicit call to ca.get() every time, not relying on the
> monitored value. That will add a potential delay, but is probably the
> safest way to ensure that the value is the current one.
to ponder whether or not the overhead of a full get() is worth it.
Seems like just reporting the newly written value is sufficient for our
purposes.