Changes between Version 4 and Version 5 of Guidelines/VxWorks


Ignore:
Timestamp:
Apr 29, 2013, 11:52:44 AM (9 years ago)
Author:
Peter Brockamp
Comment:

Added some documentation for building Boost on VxWorks

Legend:

Unmodified
Added
Removed
Modified

  • Guidelines/VxWorks

    v4 v5  
    11== Introduction ==
    22
    3 If you're not interested in the following technical details you may well skip forward to section "Patching the operating system".
    4 
    5 '''Differences to other operating systems'''
     3If you're not interested in the following technical details you may well skip forward to section [#point1 (1)].[[BR]][[BR]]
     4
     5=== Differences to other operating systems
    66
    77VxWorks is a real time operating system intended for the execution of "mission critical" tasks. This has some impact on the way things are organized and do work internally. One aspect is that it uses a completely different approach for the scheduling of tasks with different priorities. A task in !VxWorks more or less corresponds to what is known as a thread in other operating systems, but the operating system will not assign any CPU-cycles to a low priority task if another, higher priority task is ready to run. This could lead to a problematic scenario called "priority inversion problem". You may read more details about priority inversion on wikipedia:[[BR]]
    … …  
    1010The effect of a priority inversion situation is that tasks could deadlock, when competing for a resource: The classical example is a low priority task T1 owning a semaphore. Now T1 is prempted by a higher priority task T2, it doesn't get any cpu-cylces assigned anymore. Eventually an even higher priority Task T3 prempts T2 and tries to get the ownership of the semaphore. This results in a low priority task (T2) blocking a high priority task (T3), potentially deadlocking all three tasks. This obviously is a situation to be avoided and this can be done via a mechanism called "priority inversion protocol". Basically the OS temporarily boosts the priority of a low priority task owning a semaphore to the priority of the task with the highest priority trying to aquire this semaphore.[[BR]][[BR]]
    1111
    12 '''Operating modes'''
     12=== Operating modes
    1313
    1414We are talking here about the actual Version of VxWorks, for the timing being this is V6.9. Much older versions like the V5.x branch are being left aside as they are very outdated and the libraries that come bundled with it are partially not standard conformant, making it impossible to use boost. The current version of VxWorks can execute software in two modes. You can compile your project as a DKM (''D''ownlodable ''K''ernel ''M''odule, sort of a driver in Windows terms) or as a RTP (''R''eal ''T''ime ''P''rocess, sort of a normal program in Windows terms). For both modes different behaviour, available functionality and default values are present, keep that in mind for the next couple of minutes.[[BR]][[BR]]
    1515
    16 '''POSIX-conformance'''
     16=== POSIX-conformance
    1717
    1818Boost internally comes mainly in two flavors, a Windows implementation and a POSIX implementation. VxWorks in itself is not a POSIX-compliant operating system. Instead it implements the POSIX functionality via a compatibility layer (sort of a wrapper, converting POSIX function calls to native OS calls).[[BR]][[BR]]
    … …  
    3131So, solution three - patching the OS - seems to be the best solution. How do we do it?[[BR]][[BR]]
    3232
    33 == Patching the operating system ==
     33== Patching the operating system [=#point1 (1)] ==
    3434
    3535Here's a step by step instruction how to change the default attributes for POSIX-mutexes for RTP's. It's been taken mostly from a Wind River TSR:
    … …  
    5555That's it! Now, using Boost with this modified kernel should no longer cause any problems with task deadlocks! [[BR]][[BR]]
    5656
    57 
    5857== Conclusions ==
    5958
    … …  
    6261* Other real time OSes (e. g. QNX) ''may'' be prone to the problem as well, depending on the defaults used. Consult your OS' documentation to gain clarity about this.
    6362* Here's another useful piece of information concerning VxWorks' POSIX-functionality in general:[[BR]] At the time a task calls it's first POSIX-function during runtime it is being transformed by VxWorks 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. Calling {{{thread_self()}}} to initiate the transformation is BTW an official recommendation by Wind River.
    64 * Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it. I'll save the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the workbench build boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53. Create a Workbench project for your boost directory and copy this content to a text file called {{{.wrproject}}}, replacing the file automatically generated by the workbench. Adapt to your personal needs. No warranty whatsoever!
     63* Building Boost for VxWorks is not quite an easy task! At least I couldn't find out how to use bjam to do it. I'll save you the technical details, but it would be neccessary to make bjam call VxWorks' compiler (a patched, renamed GCC or the diab-compiler) inside of the VxWorks Development Shell (a special shell with lot's of environmental variables set). You can circumvent this for the time being by having the workbench build boost itself.  Below you will find for your convenience the {{{.wrproject}}}-file I use for Boost V1.53.
     64  1. Create a Workbench project for your boost directory and copy this content to a text file called {{{.wrproject}}}, replacing the file automatically generated by the workbench.
     65  2. Adapt to your personal needs.
     66  3. Static linking boost to your project will be OK, though I haven't tested dynamic linking.
     67  4. I use environment variables to announce the local directories for Boost and other libraries I use. These are called {{{BOOST_ROOT}}}, {{{BZIP2_ROOT}}}, {{{ZLIB_ROOT}}} etc. Create this system variables appropriately or use your own hardcoded paths (Change the include settings of your project).
     68  5. The file below is for the GCC compiler, as I don't use the diab-compiler, and for x86 as a platform. For other settings you are on your own.
     69
     70  No warranty whatsoever!
    6571{{{
    6672<?xml version="1.0" encoding="UTF-8" standalone="no"?>