EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  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  <19981999  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: Proposal for boosted Symb device support
From: Jeff Hill <[email protected]>
To: "'Benjamin Franksen'" <[email protected]>, "[email protected]" <[email protected]>
Date: Thu, 12 Mar 1998 10:12:26 -0700
>  Is it even guaranteed for the simpler line
> 
> 	vxvar = pao->val;
> 
> where vxvar is a globally visible variable of type double?

I agree that it would not be a good idea to assume so in a portable source code.
I will still argue that a mutex semaphore should be used in favor of intLock()/intUnlock()
in task level code. Even if the locking interval is currently quite short, you or some
other developer who may not be as keen on these issues will invariably
need to expand the amount of code in-between the lock calls. I hope that
this person, despite schedule and time pressures, is conscientious and therefore is
willing to write the additional code require to initialize and use the mutex semaphore.
I am also concerned about what would happen to the system if for any reason
an exception was generated (say a floating point exception or a bus error) while 
intLock() is applied. On some architectures a floating point exception can occur
when loading an invalid floating point number. The key difference is that intLock()
is a global operation with side effects on the entire system, and semTake() will only 
have side effects on tasks using the mutex semaphore. It is much easier to 
understand (and predict the failure modes of ) a system that is made up of smaller 
components that minimize their global side effects.

Jeff


Replies:
Re: Proposal for boosted Symb device support Benjamin Franksen

Navigate by Date:
Prev: Re: synchronizing client requests & completions Tim Mooney
Next: RE: synchronizing client requests & completions Jeff Hill
Index: 1994  1995  1996  1997  <19981999  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: Proposal for boosted Symb device support Ned Arnold
Next: Re: Proposal for boosted Symb device support Benjamin Franksen
Index: 1994  1995  1996  1997  <19981999  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·