EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks
From: "Jeff Hill" <[email protected]>
To: "'Ernest L. Williams Jr.'" <[email protected]>, "'Kim, Kukhee'" <[email protected]>
Cc: "'EPICS core-talk'" <[email protected]>
Date: Thu, 8 Sep 2011 18:28:30 -0600
> 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? 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?

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



Replies:
Re: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks Ernest L. Williams Jr.

Navigate by Date:
Prev: RE: 3.14 branch broken for older vxWorks Jeff Hill
Next: Re: 3.14 branch broken for older vxWorks Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: 3.14 branch broken for older vxWorks Andrew Johnson
Next: Re: EPICS and SMP: target board ==> ivme7210 ==> OS ==> vxWorks Ernest L. Williams Jr.
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  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 ·