EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: V4 EpicsString
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Sat, 9 Jul 2005 02:19:22 +0200
Hi Andrew,

you raise a number of valid objections (to using GC and thus, it seems, 
Cords), most of whom I cannot readily disprove. I have been reading up 
on the details of the Boehm GC and in fact it seems that its 
incremental collection scheme relies on virtual memory or else on the 
user notifying the GC whenever objects are going to be modified.

Just for the record: there /are/ GCs with hard real-time guarantees. The 
problem is that they move life objects around and thus cannot be easily 
used for a conservative collector. They also seem to need some sort of 
'write barrier' that can only be implemented efficiently with the help 
of virtual memory systems. So: no luck for our good old Motorola 68k 
boards.

I will try to find out if the basic idea behind cords can be made to 
work without a real GC behind it. Maybe using reference counts can be 
made to work efficiently in this special case. Also, there seem to be a 
number of papers that discuss methods to avoid most or at least some of 
the cost of locking reference counters against concurrent access.

However, even if it turns out that we cannot use Cords/Ropes as such for 
EPICS V4 (because I fail to come up with an efficient implementation 
that doesn't need a real GC), it may /still/ be worthwhile to consider 
an interface to strings which does not allow destructive update of an 
already constructed string.

Why? Because string data is normally not overwritten at some arbitrary 
position. Instead, if the string is modified at all, it either gets 

- replaced completely, or else
- new data is incrementally appended

I would bet that 99% of all string modifications follow one of these two 
patterns. The first one is typical for dbAccess-type modifications 
(including dbPut, dbPutLink) but also inside and in betwen record and 
device support. The second one is used mostly when reading from a file; 
the string typically ends up being completely constructed and then 
stored somewhere, following the first pattern. Thus it seems to me that 
a representation in which a string, once it is finally constructed, 
cannot be changed any longer, would be quite practical for EPICS. The 
remaining few cases that don't follow this pattern can probably be 
handled by resorting to ordinary plain char arrays. For this to work 
well, we would need /two/ string types: one that allows to append stuff 
at the right end, and another one for immutable strings. A problem is 
that neither is a subtype of the other, so conversion between the two 
must be thought out carefully. I'll try to come up with a concrete 
proposal...

Ben

References:
V4 EpicsString Benjamin Franksen
Re: V4 EpicsString Andrew Johnson

Navigate by Date:
Prev: Re: Record support and user-defined fields Benjamin Franksen
Next: Re: Record support and user-defined fields Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: V4 EpicsString Andrew Johnson
Next: SNL improvement and ideas Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·