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]>, EPICS Techtalk <[email protected]>
Date: Thu, 12 Mar 1998 14:10:52 -0700
> I agree that intLock/intUnlock is dangerous in the situations you
> describe. On the other hand: what if you have some external SW package
> that you cannot or don't want to modify, and that installs an interrupt
> handler that updates your global variable. Then you will have a problem
> with the semaphore solution because your SW package does not know
> anything about it. I think the Symb device support should be able to
> handle such a situation safely.
> 
> The argument about affecting the whole system (intLock) vs. small
> components (mutex semaphore) is a good one, but mind that we are talking
> about a _globally_ visible object that _any_ instance in the system can
> modify, even the user from the shell. I see no other way to protect such
> a variable globally but by a global mechanism.

Sorry to nit pick, I obviously was not thinking about your unique situation. I Agree that 
if the user is changing the variable from the shell or any other task level program 
that does not use the mutex semaphore then at least taskLock() will be required, 
and that if ISRs are involved then intLock() will be required to solve both problems. 
If multiple processors and also interrupts are involved then a global solution may 
prove to be elusive. I still worry that an exception might occur while intLock() is applied,
but perhaps this risk is worth taking in order to allow unconstrained synchronized 
access to globally known variables.

Jeff


Replies:
Re: Proposal for boosted Symb device support Andrew Johnson

Navigate by Date:
Prev: Re: Proposal for boosted Symb device support Benjamin Franksen
Next: Reminder on the FREE CapFast evaluation software Dr. Chong Lee
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 William Lupton
Next: Re: Proposal for boosted Symb device support Andrew Johnson
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 ·