Experimental Physics and Industrial Control System
|
Jeff Hill wrote:
Looks like we need an OSI layer for spinlocks.
Jeff, will it be quick for you to give us an implementation?
Then we would test on vxWorks as well as linux.
There are several issues that need to be discussed.
1) On certain OS such as windows the epicsMutex is in fact already
implemented with a hybrid type of spinlock, and presumably that might be
true also on other SMP OS.
2) We might be able to implement an OS independent spinlock with the
epicsAtomics library as long as we presumably also embed an epicsEvent in
the spin lock object so that we have something to wait on if the spin count
decrements down to zero.
3) We might actually end up implementing a worse spinlock than the OS has
already provided because an epicsEvent per mutex might consume more
resources, and also might be slower, than what the OS implementers might use
for implementing the wakeup for spun down spinlocks.
4) Other designs I am not thinking of at the moment just might be better.
The bottom line: we need to proceed carefully when trying to outsmart the OS
when implementing a Mutex. Note that there is definitely some déjà-vu factor
here as some will even recall that there was actually such an attempt tried
in the early days of EPICS based on the vxWorks vxTas function but this
"fast lock" implementation was at some point eliminated from base after it
was decided that it wasn’t a better alternative to using an ordinary vxWorks
mutex.
Does vxWorks have actually two implementations, an ordinary mutex and also a
spinlkock mutex?
Yes, WRS provides binary semaphores and spinlocks.
This is definitely what windows did. They have one mutex
that works between processes, and faster spinlock-based mutex that works
only between threads. I chose the in-process version for implementation of
the epicsMutex. Does the vxWorks version of a spinlock wait internally on an
event flag (or some other os internal primitive) when it has spun down (but
never obtained the lock), or does it return an error in that situation?
*spinLockNdTimedTake( )
<https://support.windriver.com/pub/secure/com.windriver.ide.doc.vxworks/vxworks_kernel_api_reference_6.8/spinLockNdTimedLib.html#spinLockNdTimedTake>*
routine takes a /timeout/ argument. This argument specifies a maximum
period of time to wait to acquire a lock.
Reference:
https://support.windriver.com/olsPortal/faces/basic/manual.jspx?_afrLoop=84075587832000&contentId=034925&_afrWindowMode=0&_adf.ctrl-state=dnlnwc6h3_24
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
-----Original Message-----
From: Ernest L. Williams Jr. [mailto:[email protected]]
Sent: Wednesday, September 07, 2011 3:06 PM
To: Kim, Kukhee
Cc: Williams Jr., Ernest L.; Jeff Hill; 'Andrew Johnson'
Subject: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks
Hi Kukhee,
Again, excellent work at the codeathon. :)
The INTEL board is currently booting just a Uniprocessor (UP) vxWorks
Kernel
Located here:
[ernesto@lcls-dev2 ioc]$ cd
/nfs/slac/g/lcls/build/vxWorks/ioc/vxWorks6.8-ivme7210-kernel
I have tested the above kernel with Andrew's regression tests for EPICS
BASE R3-14-12
Some notes and status on vxWorks-smp
I have created a new project:
[ernesto@lcls-dev2 ioc]$ eval
`/afs/slac/package/vxworks/devel/6.8/wrenv.sh -p vxworks-6.8 -o
print_env -f sh`
[ernesto@lcls-dev2 ioc]$ cd /nfs/slac/g/lcls/build/vxWorks/ioc
[ernesto@lcls-dev2 ioc]$ vxprj create -smp ivme7210 gnu
vxWorks6.8-ivme7210-kernel-smp
Looks like we need an OSI layer for spinlocks.
Jeff, will it be quick for you to give us an implementation?
Then we would test on vxWorks as well as linux.
Some vxWorks related notes:
**************************************************************************
**********************
CAUTION: VxWorks kernel applications must be built specifically for the
type of
system on which they will run. Applications built for uniprocessor (UP)
VxWorks,
for symmetric multiprocessor (SMP) VxWorks, or for VxWorks systems based
on
variant libraries created with a VxWorks source build (VSB) project
(either UP or
SMP), are not binary compatible. Note that the loader rejects a kernel
module if it
is not compatible with the system into which it is loaded, prints an
error message
to the console, and sets errno to S_loadLib_INCOMPATIBLE_MODULE
**************************************************************************
************************
**************************************************************************
***********************
To build a kernel application for use with a VxWorks SMP kernel using
default
libraries, use the following command syntax or add the variable
assignments to the
application’s makefile:
make CPU=cpuType TOOL= toolchain VXBUILD=SMP
The VXBUILD=SMP ensures that the application will be linked against the
default
SMP libraries.
**************************************************************************
**************************
The above note required me to create a new EPICS CROSS target:
So, in "base-R3-14-12/configure/os"
CONFIG.Common.vxWorks-pentium4-smp
CONFIG.Common.vxWorks-pentium4-smp-debug
===== CONFIG.Common.vxWorks-pentium4-smp ==========
# CONFIG.Common.vxWorks-pentium4-smp
#
# Revision-Id:
# This file is maintained by the build community.
#
# Definitions for vxWorks-pentium4-smp target archs
# Sites may override these definitions in
CONFIG_SITE.Common.vxWorks-pentium4
#-------------------------------------------------------
# Include definitions common to all vxWorks target archs
include $(CONFIG)/os/CONFIG.Common.vxWorksCommon
# Vx GNU cross compiler suffix
CMPLR_SUFFIX = pentium
ARCH_CLASS = pentium
# Add vxWorks build type to link/use smp libraries.
ARCH_DEP_CPPFLAGS = -DCPU=PENTIUM4 -D_X86_ -DVXBUILD=SMP
ARCH_DEP_CFLAGS += -mtune=pentium4 -march=pentium4
ARCH_DEP_CXXFLAGS += -x 'c++'
ARCH_DEP_CFLAGS += -fno-defer-pop
==============================================
Kukhee, EPICS BASE is sitting here in the teststand area:
/afs/slac/g/lcls/epics/TestStand/base/base-R3-14-12
The application is sitting here:
/afs/slac/g/lcls/epics/TestStand/iocTop/R3-14-12/pentium4/MAIN_TRUNK
Cheers,
Ernest
- References:
- RE: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks Jeff Hill
- Navigate by Date:
- Prev:
RE: [Merge] lp:~epics-core/epics-base/rebased-atomics into lp:epics-base Jeff Hill
- Next:
[Merge] lp:~strauman/epics-base/stacktrace into lp:epics-base Till Straumann
- Index:
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: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks Jeff Hill
- Next:
vxWorks 6.8 and "#define _VSB_CONFIG_FILE" Ernest L. Williams Jr.
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|