On Sat, 25 Sep 2004 06:38:56 -0400
"Steven T. Hatton"
I can't speak with unquestionable authority on this, but I believe you might find Java has it's own hidden legacies. Namely Small Talk and Lisp (spelled Emacs). It certainly has some history. The Java language is very C-ish by design. A few things were changed: integer sizes are explicit floating point size is explicit. char is not an integer. Dynamic memory allocation is controlled in that you can only allocate an object, and there is no explicit free as this is done automatically. The language is object oriented by design. I see absolutely no Lisp in this at all.
Threads. I consider this a plus for Java since the programmer does not need to consider different threading models.
Until very recently, I was of the opinion that C++ was better off without standardizing threading. That allows for other threading 'standards', models, or whatever you want to call them to be created to suite specific needs, or simply to allow for more innovation. Sure with Java you pretty much know what you are dealing with in all cases. But that doesn't allow for much flexibility.
There is much debate over threads. What I find problematical is not the
lack of a threading paradigm, but the lack of recognition by the
standards committees. The problem is that threadsafeness is very
platform dependent. Certainly, the STL is not really a good candidate
for being threadsafe, but the entire C runtime library could be made
threadsafe on all platforms, but that also opens a whole can of worms
for the standard people. Where Java (and ADA) win on this case, is that
the language itself specifies the thread paradigm, and the underlying
run time system must implement it.
http://people.redhat.com/drepper/tls.pdf
This is talking about Thread Local Storage. TLS is used by Microsoft and
by other vendors to provide a per-thread local storage. Vendors must
come up with a way that they can specify TLS in the soruce code, which
mandates an extension to the compiler and language. There are some
advantages to TLS in that it provides a per-thread static storage. I
also find that the performance cost of TLS is very high because of the
mechanisms used to access it. A more portable way, is to have the parent
allocate a per-thread context, and pass that context to the thread via
the pthread_create. The problem with this approach is that the
per-thread context must be globally visible to all other threads, and a
misbehaving thread can cause problems. Normally I create an array (or
other data structure) containing the thread id, thread number (locally
defined), and possibly some other information used by the thread.
--- standards issues
The problem that a language has by specifying a paradigm like threads,
is that there is an independent standards committee working on threads.
C++ has the additional problem in that there needs to be a certain
amount of C compatibility, and they need to coordinate with the C
committee also to some extent. By Java stating its own thread paradigm,
it forces its threading standard to be implemented on all platforms.
Whether it uses the POSIX or other model underneath is not really an
issue. You are also guaranteed that the standard classes are threadsafe.
--
Jerry Feldman