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: String Interfaces
From: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Thu, 28 Jul 2005 12:49:30 -0600
> Can I request that you re-read the final paragraph of that EffC++ item.
> 
> In this case there *is* a compelling reason to allow other string
> implementations to get a pointer to your segment data; because it's
> impossible for two different segmented string types to work together
> efficiently (even assignment would have to be done character by
> character) otherwise.


I'm not sure that there is a compelling reason - that there needs to be as
much performance hit as one might initially think. Consider if the string
interface has a call in it "virtual StringInterface::copy ( const
StringInterface & stringIn )". If we had that, then the native string
storage interface could, in its copy virtual method, use the block copy
method in stringIn to copy into its private storage w/o need for a scratch
pad. What do you think?

> (even assignment would have to be done character by
> character) otherwise.

Block by block, you mean I assume?

> 
> Your concerns about multiple threads are irrelevent since if the string
> is not already properly protected by an external mutex it can be changed
> in between two character-by-character reads, which is probably breaking
> some other promise you made to the user of the string when you handed it
> out.

Granted, but I still worry that some thread will keep a copy of the private
pointer and keep accessing the string after the mutex has been released.
Also, there are still lifetime issues which are typically managed
independently of mutexes.

> 
> You're already presenting us with another API that requires us to give
> out handles to internal data: A propertyCatalog::traverse() function has
> to trust that the propertyViewer/propertyManipulator isn't going to take
> and store the address of the reference it has to give out.

I don't see that the situation is the same. In the DA reveal() situation the
data is passed as a reference argument to a reveal() function call. I think
that we all operate on the built in assumption that well written functions
do not save the address of their incoming arguments and reference them after
the function returns.

In the string interface we are a raw pointer *is* saved after the function
returns and I do feel that it's really unclear in those situations what the
useful lifetime of the pointer received will be. Some other thread may
destroy the data while we are accidentally still using it.

> 
> 
> >>If not, please describe how you would write an efficient comparison
> >>operator between two different segmented string implementations.
> 
> Note the words I used: "two different segmented string implementations."
> 
> > If not then we drop back to a slower generic version that
> > requires copying into a scratchpad, but since that situation will occur
> only
> > when crossing between subsystems or when transitioning from an old
> string
> > implementation to a new one then perhaps the overhead would be
> acceptable.
> 
> I disagree that this is acceptable, because I see it as being very
> common to have multiple implementations.  I can see requirements for at
> the very least two if not three or four inside of iocCore, and that's
> before considering your needs inside of CA.

The problem for DA is that it *does* need to compare two strings of unknown
type. One may be an EpicsString and another may be a C string constant and
another may be a std::string. A primary design guideline for DA is to not
make storage format constraints, and not all string storage formats will be
inclined to return a private pointer. 

> 
> > PS: I would also like to see strings accessed through a pure virtual
> > interface class so that multiple implementations are possible. This is,
> > among other apple pie reasons, because DA is interfacing with the world,
> and
> > the world will use many different string implementations including
> > std::string.
> 
> If you give me my request, I'll give you that one.
> 

Compromise is good, and I am ready to move on, but I am still uncertain
that:

A) DA will be able to interface to a wide range of string storage
implementations if we have an interface returning a pointer to the private
string. Not all string storage formats will be inclined to return a private
pointer.

B) I am not convinced that we have a compelling performance reason to return
a handle to private internal storage. If we add a "virtual
StringInterface::copy ( const StringInterface & stringIn )" method then
performance can be good w/o need for the method returning a handle to
private storage.

Jeff



Replies:
Re: String Interfaces Andrew Johnson
References:
Re: String Interfaces Andrew Johnson

Navigate by Date:
Prev: Re: V4 CA example timeStamp, sevr, status, data Marty Kraimer
Next: primitive data types, was: ICE and TIPC Kay-Uwe Kasemir
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: String Interfaces Andrew Johnson
Next: Re: String Interfaces Andrew Johnson
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 ·