Experimental Physics and
Industrial Control System

On 11/2/2010 10:17 AM, Ernest L. Williams Jr. wrote:

Tim Mooney wrote:

Dear folks,

I have two records, and a separate task monitoring a field that both records
post, all in the same IOC. Most of the time, my task receives monitors in the
order in which they were posted. But sometimes, the task receives a monitor
from record B before it receives a previously posted monitor from record A.
(I know for sure which record is posting first, because record A posts before
causing record B to process. Also, I've modified the record to set its time
stamp immediately before posting, and I get another time stamp on entry to
the monitor routine. The time ordering of those stamps does not agree.)
I've seen this on solaris and Linux, but not on vxWorks.

Hi Tim,

When you run an IOC on Linux the EPICS Priorities are not map properly unless you run the IOC as root.
All tasks are given the same OS priority.
Are you running the Linux IOC as root?

No. Although the original problem was reported for a Linux system, most of my
testing has been on solaris. Do you know if this also applies to solaris?

flora02:iocBoot/ioctestStatsSoft>../../bin/solaris-sparc-gnu/testIocStats
epics> < st.cmd
#!../../bin/linux-x86/testIocStats
< envPaths
epicsEnvSet("ARCH","linux-x86")
epicsEnvSet("IOC","ioctestStatsSoft")
epicsEnvSet("TOP","/afs/slac.stanford.edu/u/qb/saa/spear/iocStats")
epicsEnvSet("EPICS_SITE_TOP","/afs/slac/g/spear/epics")
epicsEnvSet("EPICS_MODULES","/afs/slac/g/spear/epics/modules")
epicsEnvSet("SNCSEQ","/afs/slac/g/spear/epics/modules/seq/seq-R2-0-12-spear1")
epicsEnvSet("EPICS_BASE","/afs/slac/g/spear/epics/base/")
cd /afs/slac.stanford.edu/u/qb/saa/spear/iocStats
#
# do OS-specific startup here
#
epicsEnvSet("ENGINEER","engineer")
epicsEnvSet("LOCATION","location")
# Soft IOCs only
epicsEnvSet("STARTUP","/afs/slac.stanford.edu/u/qb/saa/spear/iocStats")
epicsEnvSet("ST_CMD","st.cmd")
## Register all support components
dbLoadDatabase("dbd/testIocStats.dbd",0,0)
testIocStats_registerRecordDeviceDriver(pdbbase)
## Load all record instances (VxWorks)
#dbLoadRecords("db/iocAdminVxWorks.db","IOC=IOCTEST")
## or load only those records for RTEMS IOCs
#dbLoadRecords("db/iocAdminRTEMS.db","IOC=IOCTEST")
## or load only those records for Soft IOCs
dbLoadRecords("db/iocAdminSoft.db","IOC=IOCTEST")
## optionally load the SCAN monitoring records
dbLoadRecords("db/iocAdminScanMon.db","IOC=IOCTEST")
dbLoadRecords("db/testIocAdminRelease.db","IOC=IOCTEST")
iocInit()
Starting iocInit
############################################################################
## EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$
## EPICS Base built Aug 31 2010
############################################################################
iocRun: All initialization complete
#seq(&testSuspension)
#seq(&testCpuUse)
epics> epicsThreadShowAll
           NAME     EPICS ID   PTHREAD ID   OSIPRI  OSSPRI  STATE
         _main_        23fd8            0      0       0       OK
         errlog        2b470            2     10       0       OK
         taskwd        3e138            3     10       0       OK
     timerQueue        337a8            4     70       0       OK
          cbLow        30630            5     59       0       OK
       cbMedium        80828            6     64       0       OK
         cbHigh        808f8            7     71       0       OK
       dbCaLink        30770            8     50       0       OK
     timerQueue        30bf8            9     60       0       OK
       scanOnce        975d8           10     70       0       OK
         scan10        97f20           11     60       0       OK
          scan5        97fb8           12     61       0       OK
          scan2        98050           13     62       0       OK
          scan1        980e8           14     63       0       OK
        scan0.5        98180           15     64       0       OK
        scan0.2        98218           16     65       0       OK
        scan0.1        982b0           17     66       0       OK
        CAS-TCP        9be98           18     18       0       OK
     CAS-beacon        9bf68           19     17       0       OK
        CAS-UDP        9c038           20     16       0       OK

Cheers,
Ernest

I have code that misbehaves when this happens, so I started digging around
and have convinced myself that I should not be relying on the time ordering of
monitors received from different records (even when those records are running
in the same task). I now think I can rely on posts from a single record arriving in
time order, but not posts from different records. I think this because events from
different record go into different queues, and there doesn't seem to be any code
in the vicinity that seems worried about time ordering across event queues.

Am I right about this?

References:

monitors received out of order Tim Mooney

Re: monitors received out of order Ernest L. Williams Jr.

Re: monitors received out of order Tim Mooney

Navigate by Date:

Prev: Re: EPICS Suggestions and Priorities Andrew Johnson

Next: RE: monitors received out of order Jeff Hill

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: monitors received out of order Tim Mooney

Next: Open group leader position for DAQ & controls at PSI, Switzerland Luedeke Andreas

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <2010>  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024