EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Patch: Move alarm.h and rename alarmString.h
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Mon, 29 Jun 2009 22:21:41 +0200
On Samstag, 13. Juni 2009, Andrew Johnson wrote:
> Michael Davidsaver suggests we make the changes in the attached patch,
> which moves alarm.h from src/dbStatic to src/ca and puts the static alarm
> strings into libca.

I think it is questionable whether it is really an improvement. Alarm stati 
and severities are a central concept used all over the place in the core of 
the EPICS database, moving this stuff to CA doesn't sound right to me. What 
is the gain?

> We've never really got the alarm enums right; there are equivalent
> definitions in src/db/menuAlarmStat.dbd which must match alarm.h, and we
> currently have the header alarmString.h which currently instantiates a
> global alarm string array into whatever file it's included by.  This is
> used both internally (by catools and cap5) and externally (by MEDM, ALH,
> etc).

I think you have once proposed to simply use strings for the alarm status 
and I think this is a step in the right direction. What makes this idea 
less attractive is that we'd have to send the whole string over the network 
each time the status is demanded. This could be avoided if EPICS offered 
support for internalized, immutable strings; let's call them 'atoms' (just 
to have a name). The idea is that you can register a string and get back a 
unique integer value that can be sent around at a constant small cost, 
similar to the current EPICS enumerations. But in contrast to the latter, 
new atoms can be created at runtime and they do not have to be numbered 
sequentially. This would be ideal for things like alarm status and other 
kinds of enumerations which need to be extensible at runtime. In fact, it 
is a safe bet that a huge majority of strings in an IOC are (at least 
conceptually) immutable and so could use this feature. You might argue that 
you loose the (runtime-) 'typing' that is associated with enumerations, 
i.e. we can recognize invalid enumeration values. However, keeping a list 
(array) of valid atoms around and checking whether a supplied atom is an 
admissible value would be as easy or hard as it is now.

As to implementation of such a feature, this would be easy in a single 
process (just use a hash table), but of course we want the returned 
identifier to be unique across a whole site, which is not quite as trivial. 
Off the top of my head I see three ways:

(a) centralized service

Easiest to implement, but single point of failure, high startup cost, but 
can be amortized by caching on the IOCs and clients.

(b) distributed service

Like (a) but no central server, instead each IOC replicates what all the 
others have, clients may cache. Ambitious: no idea whether there are 
efficient algorithms for the synchronization; extra points for detection 
and recovery from inconsistencies ;-)
  
(c) cryptographic hash

Most elegant, no communication overhead because string->atom is just a pure 
function (no side effects, no dependency on order of calls). But may be 
impossible to compress into 32 or even 64 bits with a negligable 
probability of collision. I am not enough expert to judge.


In any case, adding something like this to EPICS would need serious 
addition(s) to the CA protocol, although not necessarily incompatible ones.

Cheers
Ben

Replies:
RE: Patch: Move alarm.h and rename alarmString.h Davidsaver, Michael
References:
Patch: Move alarm.h and rename alarmString.h Andrew Johnson

Navigate by Date:
Prev: RE: Patch: Move alarm.h and rename alarmString.h Jeff Hill
Next: Message values and message texts. Rees, NP (Nick)
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Patch: Move alarm.h and rename alarmString.h Jeff Hill
Next: RE: Patch: Move alarm.h and rename alarmString.h Davidsaver, Michael
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  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 ·