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
<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
- 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
<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
|