Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 29 Sep 2005 14:19:24 -0500

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System