Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 11 Aug 2011 11:10:55 -0500

Hi Benjamin,

On 2011-08-09 Benjamin Franksen wrote:
> (1) Static objects should be avoided wherever possible.
> 
> (2) If static objects are used, the constructor should be trivial, i.e. not
> perform anything except setting members to default values.

We can't enforce that as a hard rule — Eric's example of registering iocsh 
commands is one, and there are others.  Maybe we need to document which EPICS 
APIs /can/ be used in static initialization code and which /can't/.

On vxWorks and some RTEMS systems the NTPTimeSync and ClockTimeSync threads 
are started from a static initializer, and they also get registered with the 
taskwd subsystem which lazily starts its own thread as a result:

mv6100> ld 0,0, "test.munch"
value = 515189984 = 0x1eb52ce0
mv6100> i
  NAME        ENTRY       TID    PRI   STATUS    PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- ------ -------- ------- -----
tExcTask   excTask      1effcc30   0 PEND       1e9b18 1effcb10   3006b     0
tLogTask   logTask      1effa060   0 PEND       1e9b18 1eff9f50       0     0
tShell     shell        1edbf600   1 READY      1e368c 1edbf200  8800dd     0
tNetTask   netTask      1ef70c40  50 PEND       1dddc0 1ef70b50       0     0
NTPTimeSync1eaf5a54     1eb51730 109 PEND+T     1dddc0 1eb515a0       0  3404
ClockTimeSy1eaf5a54     1eb4f1d0 109 PEND+T     1dddc0 1eb4f050       0  3400
taskwd     1eaf5a54     1edc9d30 189 PEND+T     1dddc0 1edc9bb0       0   155
value = 0 = 0x0

> (3) Non-trivial initialization for complex objects should be done in a
>  regular method either lazily ("Construct On First Use") or by an explicit
>  call from some startup routine. The latter has the advantage of a
>  well-defined order of initialization; the former is sometimes more
>  convenient.

There is a major thicket here which needs careful examination...

> (4) Starting threads inside static initialization is a bad idea and should
>  not be allowed (see rule 2).

I agree that in principle we shouldn't allow calls to epicsThreadCreate() from 
static constructors, but we already have several examples above which can't 
easily be changed, and anything that calls an errlog routine from a static 
constructor will lazily start the errlog thread for some more.

> (5) epicsThreadOnce should also be avoided wherever possible. Using it
>  means objects cannot be freely passed between threads which is detriment
>  to composability.

But as Jeff implied, epicsThreadOnce() is essential to coding lazy 
initialization correctly on an SMP system.

I don't know what the best solution is to all this, but I do know that we 
can't just write down a set of rules without examining all our subsystems and 
making changes to bring them into compliance.

I would definitely favor improving the performance of epicsThreadOnce() for 
those subsystems that currently use lazy initialization though.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System