Solaris's impressive ABI compatibility
There are some things that Solaris is very good at; one of them is user-level ABI compatibility (at least for basic programs). As an illustration of just how good it is, I only recently noticed that on our Solaris 8 machines I am still routinely using some dynamically linked programs compiled in August of 1993 (which is probably when this group started using Solaris machines).
I hadn't noticed before now because the programs hadn't really changed since then (so I had no need to upgrade them), and because the compiled versions just kept on working so I didn't have to pay attention to them.
(Until recently, my Solaris version of
rc was a statically linked
binary from March 1994. I can't claim this as an unqualified success,
because I was goaded into replacing it with a current version by an
obscure glitch in some circumstances. But it's pretty striking that
I didn't have any problems in normal use.)
My Solaris binaries that use X have fared less well, although this may be because X environments themselves have changed significantly since 1994. (For example, back then programs could get away with not dealing with TrueColor displays, especially 24-bit and 32-bit ones.)
(The program itself starts up, but fails with a BadMatch 'invalid parameter attributes' error on an X_PolyFillRectangle call. I wonder if I can dig up an 8-bit PseudoColor display somewhere around here to test it against; unfortunately Xnest can only force a PseudoColor visual as the default visual if the underlying X server has one to start with, and modern X servers and hardware don't seem to.)
Link: Threads Cannot be Implemented as a Library
We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.
There is also a discussion of this paper at Lambda the Ultimate that may be interesting
reading. On a quick skim of the LtU discussion thread, this
jumps out as a useful summary of the entire
multiprocessor programming issue, ending up with the conclusion that
volatile is both unnecessary and harmful in shared-state