1.9 Unsafe codes and real time programs

.NET literature uses the term 'unsafe code' to refer to code which involves pointer operations. ^[44] Only certain .NET languages, including C# and Visual C++ .NET, support unsafe coding. ^[45]

^[44] C/C++ programmers will be familiar with pointers (and the bugs they often bring). As for Java programmers, pointers (or, more accurately, pointer variables) are just variables which contain the memory addresses of another variable.

^[45] In C#, unsafe codes must be used within code blocks marked with the unsafe keyword.

Using pointer operations, you can perform some tweaking to optimize your codes. A good example is implementing your array 'object' on the stack (like Java, arrays are objects in the various .NET languages). If you write safe codes, all array objects that you instantiate will be created on the heap. On the other hand, you can implement your own array storage structure on the stack using pointer operations. If you are careful about it, the result is a very efficient and fast array structure. You can read and write directly to memory locations using pointer operations “ they offer you lots of flexibility and power.

Nevertheless, pointer operations come with their own set of problems “ it is very easy to write code involving pointers that can result in extremely difficult-to-find logical bugs (that's one reason why pointers are passed off in Java).

On the other hand, safe codes are relatively easier to write and debug. Safe codes are also type-safe. For example, it is impossible to refer to an index of an array that is out of bounds.

Going by .NET's definition of 'unsafe codes', since Java does not allow direct memory manipulation via pointer operations, it is a totally 'safe' language.

Java is facing a huge problem in the real time industry because the JVM is more a liability than an asset when it comes to real time issues. Performance has always been an important factor in the real time world, and real time engineers don't like the idea of not being able to control the JVM. In most cases, Java's apparently random non-deterministic garbage collection mechanism simply throws Java out as a potential language for writing real time applications. ^[46]

^[46] Nevertheless, work is being done on adapting Java for use in real time applications. Sun has published a Real Time Specification for Java. The J-Consortium (www.j-consortium.org), an independent organization, has also come up with their own real time specifications for Java.

When you want to write to memory mapped devices in Java, there is no choice except to turn to JNI. Every respectable Java programmer knows the disadvantages of using JNI “ not only do you need another C/C++ programmer in your team to code the native codes, there are also performance overheads.

With C#'s unsafe coding capability, you can write C# codes that use pointers and access memory locations directly. Such C# codes may directly communicate with the underlying Win32 API functions which take in pointers as parameters, and write directly to memory mapped devices.

It is unlikely that the real time industry will rush out to embrace C# because of its ability to write unsafe codes. In fact, real real time projects with very strict performance limitations avoid object-oriented (OO) languages altogether (even C++). ^[47] C and assembly would still be the reigning languages of the real time world.

^[47] OO features such as class inheritance and polymorphic method invocation carry pricey overheads.

Nevertheless, the ability to read/write directly to memory is a breakthrough “ something useful that you can't do in pure Java.