Changes between Version 10 and Version 11 of Guidelines/VxWorks

Timestamp:

Apr 29, 2013, 12:20:38 PM (9 years ago)

Author:

Peter Brockamp

Comment:

--

Guidelines/VxWorks

@@ -26 +26 @@
 Almost all mutex-instances used by Boost do use the default values, which at glance appears logical - it's the OS' resposibility to choose the proper default! But here's a little dilemma: What is a proper value depends on what you're trying to do, the ball is passed back to Boost from the OS. Now you could pass it over from Boost to the user: Boost can't know what is a proper value, it depends on what the user tries to do! I think you got the problem, right?[[BR]]
 So, how will we get out of this dilemma (or is it even a tri-lemma)? Three possibilities:
-* Implement an interface, allowing the user to choose the proper value for his/her application. This is not really an option! It will bleed out deeply burried implementation details to the user, resulting in unportable, error prone code and it force the user to study mutex details for a specific platform - whereas he just wanted to use e.g. a {{{shared_ptr}}} on Windows - Yuk!
+* Implement an interface, allowing the user to choose the proper value for his/her application. This is not really an option! It will bleed out deeply burried implementation details to the user, resulting in unportable, error prone code and it forces the user to study mutex details for a specific platform - whereas he just wanted to use e.g. a {{{shared_ptr}}} on Windows - Yuk!
 * Change the implementation of all Boost libraries to use mutexes with non-default attributes. This would be viable and would not interfere with the non-Boost part of a user application. But it has the disadvantage to be very fragile. If with a new version of Boost all in a sudden a library starts using mutexes the priority inversion problem will resurrect every once in a while.
 * Change the operating system to use other defaults. This may at first sound odd for users of a closed source system, but VxWorks in its latest versions luckily comes with the source code included and the possibility to compile a new kernel adapted to your needs. So, this has a lot of advantages, but it may interfere with the user's code (e. g. when he's using POSIX-mutexes with default values). Anyway, this should not pose a major problem, obeying the priority inheritance protocol does not break anything, it just puts on some additional burden on the task-scheduler where it wouldn't be neccessary. But if utmost performance, predictability and timing accuracy were paramount for your application you would probably not be using C++, the heap and Boost, right?