Experimental Physics and Industrial Control System
Tim Mooney wrote:
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?
Sorry, for my late reply as I did not have a Solaris machine.
The same problem indeed happens on Solaris as confirmed by Stephanie
Allison.
Here is epicsThreadShowAll on solaris 10:
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
epicsThreadShowAll() will clearly show this.
On the other hand Windows does map the thread priorities as a normal
user. :)
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
2025
- 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
2025