To view parent comment, click here.
To read all comments associated with this story, please click here.
It used to be true several years ago in VxWorks that all global variables were global, but that was when you could only have kernel applications. Now with Real-Time Processes (RTPs) added, each address space can have its own global variables. They can be of the same name as in other RTPs (or in the kernel) if desired (good for spawning multiple copies of an RTP from one copy in flash to differently named tasks). In multi-core VxWorks SMP, the Memory Management Unit protects all of the data and code in RTPs not intentionally shared. Data can be shared in Shared Data Regions and code in Shared Libraries.
That is good. Globals are bad enough as is; making them REALLY global, with no method for finding namespace conflicts or thinking you're writing to MyVar1 when you've typo'ed it to MyVarl is a big problem (In submission box's font, you can't even tell that's a "one" and an "el"! It's a little better after it's "published" to the site.)




Member since:
2006-05-20
I am fairly certain that VxWorks is not a micro-kernel based system. It's one of the things that QNX brags about as being superior to VxWorks; whether that's true or not is open to debate, and VxWorks has considerably higher market share in the embedded space. One thing that always disturbed me about VxWorks is that it uses global variables as REALLY global variables. As in every program you run on the system has access to all the global variables of all the others. Naming conflicts can be a disaster. I much prefer message passing, as is native to QNX and OSE.