EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: enhanced seq record
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Mon, 30 Jan 2006 10:34:39 +0100
On Monday 30 January 2006 10:05, Luedeke Andreas wrote:
> Benjamin Franksen wrote:
> >On Saturday 28 January 2006 00:52, Chestnut, Ronald P. wrote:
> >>If you do change the seq record (or make a new one), can you please
> >>change the behaviour for a "0" delay? Now a new thread is started
> >> for each (DOL/LNK) pair. If the delay is zero, can you "just do
> >> it" in the same thread? We found that for some big "explosions"
> >> (nested SEQs) the task switching dominates the processing time.
> >
> >[...]
> >
> >However, it /does/ request a callback for each group, regardless
> > whether the delay is zero or not, and this can indeed cause
> > unnecessary context switches. So, yes, I will change this. Adjacent
> > link groups with zero delay will be processed in a synchronous
> > manner i.e. w/o requesting a callback.
> >
> >Thanks for the hint.
>
> If I remember correctly the "seq" record is 100% asynchronous.

True.

> If you specify delays of "0", all DOLn links are supposed to be read
> at the same time.

This would be impossible. It is also not true. Current seq record reads 
each inp link (and writes corresponding out link) in a separate 
callback.

> How do you want to do this without a callback?
> (You need it to place the value into DOn when it's received and then
> write it to LNKn.)

What's wrong with doing getLink-putLink cycle for multiple link groups 
in a loop (as long as their delays are all zero)?

> But of course it would be sometimes useful to have a synchronous
> process chain,
> where the next link is processed after the the previous one completed
> and then the delay elapsed.

This is exactly how the current seq record works. Except that the out 
link is fired w/o waiting for it's completion. The sseq can do that.

Ben

References:
Re: enhanced seq record Benjamin Franksen
Re: enhanced seq record Luedeke Andreas

Navigate by Date:
Prev: Re: enhanced seq record Luedeke Andreas
Next: Patches for ARM Linux target Denison, PN (Peter)
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: enhanced seq record Luedeke Andreas
Next: RE: enhanced seq record Mark Rivers
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024