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: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 12 Mar 1998 15:03:53 +0100
Jeff Hill wrote:
> 
> On Tuesday, March 10, 1998 8:46 AM, Andrew Johnson wrote:
> > Benjamin Franksen wrote:
> >
> > > another proposal (suggested by Goetz Pfeiffer): Currently there is a
> > > 'Symb' device support for ai, ao, longin, longout, stringin and
> > > stringout records.
> > ...
> > > (1) To protect the data transport, simply add some
> > >
> > >         intLock()
> > >         ...
> > >         intUnlock()
> >
> > This is unnecessary as long as the value is read in a single cycle - for
> > longs certainly, and possibly for doubles too (I'd need to check the
> > compiler output to be sure of this one).  It may be worth doing this for
> > strings and waveforms though (added by me, see below).
> >
> 
> I agree that this is normally only required for multi-element data such
> as waveforms and strings.
> 
> It is almost always preferable to use a semTake()/semGive() of a vxWorks
> mutual exclusion semaphore instead of the intLock()/intUnlock() in task
> level code. I prefer not to cause time critical ISRs to wait while we are
> copying an array in task level code. Frequently, it is also preferable to
> specify the task delete safe and priority inheritance options when creating
> a mutex semaphore in a code that will be used at many different sites.

I was primarily thinking of scalar data (probably no more than a hand
full of machine instructions to copy them), so intLock/Unlock would be
acceptable and more efficient than using a semaphore. But I don't want
to insist on using intLock instead of semaphores. The more important
point is:

I would rather not depend on machine and compiler dependent details such
as how many processor instructions are generated for a given code line
(although I agree that in _most_ cases you are _probably_ right). This
applies especially to doubles (64 bits). Is it _guaranteed_ that 

	*((double *)(*private->ppvar) + private->index) = pao->val;

(such as happens to be in devAoSymb.c) compiles into non-interruptable
machine code? Is it even guaranteed for the simpler line

	vxvar = pao->val;

where vxvar is a globally visible variable of type double?

	Ben
-- 
The Notorious Neb Nesknarf
-----------------------------------------------------------------------
BESSY II
Berliner Elektronenspeicherring-                phone: +49 30 6392-4865
Gesellschaft fuer Synchrotronstrahlung            fax: +49 30 6392-4859
Rudower Chaussee 5                         email: [email protected]
D-12489 Berlin                       web: http://www.bessy.de/~franksen
-----------------------------------------------------------------------
HOME: Benjamin Franksen, Fichtestr. 19a, D-10967 Berlin, +49(30)6913756
-----------------------------------------------------------------------

Replies:
Re: Proposal for boosted Symb device support Andrew Johnson
References:
RE: Proposal for boosted Symb device support Jeff Hill

Navigate by Date:
Prev: Re: synchronizing client requests & completions Peregrine M. McGehee
Next: Re: Proposal for boosted Symb device support Ned Arnold
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 Jeff Hill
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 ·