Subject: [Boost-commit] svn:boost r84053 - trunk/boost/config/platform
Date: 2013-04-26 06:36:16
Date: 2013-04-26 06:36:15 EDT (Fri, 26 Apr 2013)
New Revision: 84053
Apply patch from #8494.
Text files modified:
trunk/boost/config/platform/vxworks.hpp | 83 +++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 1 deletions(-)
--- trunk/boost/config/platform/vxworks.hpp (original)
+++ trunk/boost/config/platform/vxworks.hpp 2013-04-26 06:36:15 EDT (Fri, 26 Apr 2013)
@@ -21,10 +21,91 @@
// of executables differ largely in the available functionality of
// the C-library, STL, and so on. A DKM uses a library similar to those
// of vxWorks 5.X - with all its limitations and incompatibilities
-// in respect to ANSI C++ and STL. So probably there might be problems
+// with respect to ANSI C++ and STL. So probably there might be problems
// with the usage of boost from DKMs. WRS or any voluteers are free to
// prove the opposite!
+// Some important information regarding the usage of POSIX semaphores:
+// VxWorks as a real time operating system handles threads somewhat
+// different from what "normal" OSes do, regarding their scheduling!
+// This could lead to a scenario called "priority inversion" when using
+// semaphores, see http://en.wikipedia.org/wiki/Priority_inversion.
+// Now, VxWorks POSIX-semaphores for DKM's default to the usage of
+// priority inverting semaphores, which is fine. On the other hand,
+// for RTP's it defaults to using non priority inverting semaphores,
+// which could easily pose a serious problem for a real time process,
+// i.e. deadlocks! To overcome this two possibilities do exist:
+// a) Patch every piece of boost that uses semaphores to instanciate
+// the proper type of semaphores. This is non-intrusive with respect
+// to the OS and could relatively easy been done by giving all
+// semaphores attributes deviating from the default (for in-depth
+// information see the POSIX functions pthread_mutexattr_init()
+// and pthread_mutexattr_setprotocol()). However this breaks all
+// too easily, as with every new version some boost library could
+// all in a sudden start using semaphores, resurrecting the very
+// same, hard to locate problem over and over again!
+// b) We could change the default properties for POSIX-semaphores
+// that VxWorks uses for RTP's and this is being suggested here,
+// as it will more or less seamlessly integrate with boost. I got
+// the following information from WRS how to do this, compare
+// Wind River TSR# 1209768:
+// Instructions for changing the default properties of POSIX-
+// semaphores for RTP's in VxWorks 6.9:
+// - Edit the file /vxworks-6.9/target/usr/src/posix/pthreadLib.c
+// in the root of your Workbench-installation.
+// - Around line 917 there should be the definition of the default
+// mutex attributes:
+// LOCAL pthread_mutexattr_t defaultMutexAttr =
+// PTHREAD_INITIALIZED_OBJ, PTHREAD_PRIO_NONE, 0,
+// Here, replace PTHREAD_PRIO_NONE by PTHREAD_PRIO_INHERIT.
+// - Around line 1236 there should be a definition for the function
+// pthread_mutexattr_init(). A couple of lines below you should
+// find a block of code like this:
+// pAttr->mutexAttrStatus = PTHREAD_INITIALIZED_OBJ;
+// pAttr->mutexAttrProtocol = PTHREAD_PRIO_NONE;
+// pAttr->mutexAttrPrioceiling = 0;
+// pAttr->mutexAttrType = PTHREAD_MUTEX_DEFAULT;
+// Here again, replace PTHREAD_PRIO_NONE by PTHREAD_PRIO_INHERIT.
+// - Finally, rebuild your VSB. This will create a new VxWorks kernel
+// with the changed properties. That's it! Now, using boost should
+// no longer cause any problems with task deadlocks!
+// And here's another useful piece of information concerning VxWorks'
+// POSIX-functionality in general:
+// VxWorks is not a genuine POSIX-OS in itself, rather it is using a
+// kind of compatibility layer (sort of a wrapper) to emulate the
+// POSIX-functionality by using its own resources and functions.
+// At the time a task (thread) calls it's first POSIX-function during
+// runtime it is being transformed by the OS into a POSIX-thread.
+// This transformation does include a call to malloc() to allocate the
+// memory required for the housekeeping of POSIX-threads. In a high
+// priority RTP this malloc() call may be highly undesirable, as its
+// timing is more or less unpredictable (depending on what your actual
+// heap looks like). You can circumvent this problem by calling the
+// function thread_self() at a well defined point in the code of the
+// task, e.g. shortly after the task spawns up. Thereby you are able
+// to define the time when the task-transformation will take place and
+// you could shift it to an uncritical point where a malloc() call is
+// tolerable. So, if this could pose a problem for your code, remember
+// to call thread_self() from the affected task at an early stage.
// Block out all versions before vxWorks 6.x, as these don't work:
// Include header with the vxWorks version information and query them
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk