Re: data access structures, strings

[Andrew Johnson <anj@aps.anl.gov>]

Marty Kraimer wrote:
> Thus all the IOC database needs is a:
>
> 1) nonmutable reference counted continguous string. When the reference 
> count goes to 0 the storage can be reclaimed

Since you're writing thread-safe code, the reference count also has to 
have an associated mutex to protect it from simultaneous updates from 
two threads.  Each string might have its own mutex, or we might rely on 
a single central mutex to protect all reference counts - there are 
advantages and disadvantages to either choice, although the former is 
probably better for performance since there will be many fewer clashes.

Note that a published study has shown that in a threaded environment the 
time to take and release the mutex around every increment/decrement 
operation completely nullifies the speed advantage of using reference 
counting over copying for a string implementation.  I'm not claiming 
this definitely applies in our case since their usage of the strings 
differed from ours, but the performance hit from that mutex is something 
to bear in mind.  I'm also not convinced that the string itself is the 
right place for the reference count when it's embedded in a larger data 
structure like a field descriptor or record type descriptor.

We might need more than one implementation of the nonmutable string; one 
where the storage is obtained from the system (new/malloc), and a second 
where the storage is a char* literal that must not be freed when it's no 
longer referenced.  Compiling DBD files generates literals for record 
type names, field names and menu choice strings.  I think we should just 
store the char* pointer in these cases without using any kind of string 
wrapper - if any reference count exists it would have to apply to the 
descriptor as a whole, not just to the name string.

In my design any const char* buffer or literal can be wrapped with a 
ConstString at the point of use if it has to be passed to a routine that 
takes a StringReader.  Ownership would never be passed that way though.

> What the IOC database needs for strings is very different than what 
> dataAccess requires.

However if we can agree on a common string API it will make the iocCore 
code much easier to understand overall, and will probably save us from 
duplication of common tasks.  I believe that my current design is an 
acceptable compromise, and so far nobody has raised any significant 
objections to it.

- Andrew
--
English probably arose from Normans trying to pick up Saxon girls.